[Logging] Add callback interface to logging methods for message serialization

[simianhacker]

For the Logger interfaces it would be nice if we could use a callback for the message creation so when we need to serialized data, it only happens if the logging level is enabled.

Imagine you're setting up trace logging for request/response for queries against Elasticsearch but you only want to serialized the data when trace logging is enabled (scoped to a very specific part of the application). If the response is large enough, the following code will cause a delay because regardless of the current logging level, it always runs JSON.stringify.

logger.trace(`Request: ${JSON.stringify(request)}`);
const body = await esClient.search<undefined, ResponseAggregations>(request);
logger.trace(`Response: ${JSON.stringify(body)}`);

But if if the trace method accepted string | () => string for message then we could do this:

logger.trace(() => `Request: ${JSON.stringify(request)}`);
const body = await esClient.search<undefined, ResponseAggregations>(request);
logger.trace(() => `Response: ${JSON.stringify(body)}`);

CC: @dgieselaar

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

This kind of feature (disabling expensive logging operations when the proper level is not reached) is usually achieved via distinct isLevelEnabled (that aren't implemented atm either) methods, e.g

if(logger.isInfoEnabled()) {
  logger.info(myExpensiveLogOperation())
}

But given we're using a dynamic language, I kinda like your proposal of allowing to provide a string callback instead. I think it would be acceptable to state that we don't want/need to 'log' callable objects, so it should be fine.

[pgayvallet]

Related to #144002

[pgayvallet]

In the end, we went with the more traditional approach described in #144002, which serves the same purpose.

I'll close this as resolved.