Redact potentially sensitive information in all serializable objects

[JoshMock]

Stemming from elastic/kibana#166844: serializing an object that was created by this client should redact any potentially sensitive information that object contains. This is already handled by @elastic/transport, but we have identified that improvements can be made to Error classes like ElasticsearchClientError. In short, any object that attaches request metadata (like HTTP headers, where the Authorization header, an API token, or password may be present).

Following the precedent set by Kibana, to ensure consistency, we should replace any sensitive information with [redacted].

Ideally this should happen by default, unless it's established that doing so would be a breaking change, which would require a major version bump. If it is determined to be a breaking change, a configuration option should be exposed to make it straightforward to enable redaction.

In discussion with others, the best approach is likely to identify and remove potentially sensitive data from an object at instantiation time so that it isn't in memory anywhere, thus avoiding the possibility of custom loggers or serializers accidentally circumventing the serialization techniques where this is already addressed (toJSON and [util.inspect.custom]).

cc @rudolf

[ezimuel]

@JoshMock we already have a redact system in place in elastic-transport-js, see here. This uses a custom inspect that removes sensitive data, like Headers and authentication in URL. FOr instance, this filter is executed using by console.log().

[JoshMock]

A fix for this will go out with 8.11.0, which should be published tomorrow.

In the meantime, I've published @elastic/elasticsearch-canary@8.11.0-canary.1 which includes this improvement.