[Vortex] Patch: Use "const" appropriately in API; add logging mutex

[Francis Brosnan Blazquez]

Hi Jens,

> his patch for Vortex 1.0.12 does two things:
> 
> (1) Makes the public API use "const char*" correctly, by adding a  
> bunch of "const" keywords. The exceptions are parameters where
> Vortex  
> may modify or free the string passed in, and return values where the  
> client is expected to free the pointer.
> (This should not cause any compatibility issues for client code, as
> a  
> parameter that had a "const" added still accepts any value that it  
> used to accept.
> I did not add "const" keywords in callback declarations, since
> adding  
> those _would_ break client code at compile time.)

Ok.

> (2) Wraps a mutex around _vortex_log_common, so that multiple
> threads  
> won't log to stdout simultaneously and get their messages tangled
> up.  
> I was finding the logging output very hard to read without this.
> (The mutex is only created if logging is enabled, and only used
> while  
> printing log messages, so it shouldn't have any effect on normal  
> performance.)

Looks good Jens. I've applied the patch with some additional changes:

1) __vortex_sasl_auth_data_sanity_check and
__vortex_sasl_initiator_do_initial_step weren't updated to the const
char * decl.

2) vortex_connection_set_data_full can't be updated to the const char *
declaration for the key parameter because the function receives a key
destroy function.

3) vortex_frame_get_error_message code parameter was not updated to use
const char *.

I've also updated the vortex log API to allow configuring if the mutex
should be acquired or not while logging. 

- vortex_log_acquire_mutex
- vortex_log_is_enabled_acquire_mutex

This is because testing the patch with the always lock before log
activated, shows an important performance penalty. 

In the same direction, having this activated makes the global context
execution to behave in a really different way (than executing without
log) because all threads are synchronized by log calls
(_vortex_log_common) producing a different thread execution context
(with great probabilities to dissolve "magically" a possible threading
problem you are trying to debug...;-)

By default the mutex log is not activated until a call to
vortex_log_acquire_mutex is done.

Thanks for reporting and fixing!

> --Jens
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.