DeprecationLogger's deduplication performance

[markharwood]

As part of types removal we discovered that DeprecationLogger.deprecatedAndMaybeLog() calls were the source of a big performance regression.
I suspect the bulk of the performance cost is in the use of the extractWarningValueFromWarningHeader method which has to parse prior logged messages to reject any duplicates.
Since that discovery we have implemented our own upstream event thinning in the bulk indexing API and now search APIs to reduce the number of duplicate deprecation calls.
The remaining concern is that other areas of the system may be tempted to make the same mistake given the logging API advertises a de-duplicate function through the use of a common key. Even if developers are aware of the poor performance they may not have a single loop (like in bulk indexing) where it is convenient to add the required trimming of log calls.
If the DeprecationLogger implementation was made more efficient this would help with all these concerns.

[elasticmachine]

Pinging @elastic/es-core-infra

[jasontedor]

I started attacking #35754 after a discussion in our team discussion meeting today. For the performance regression there, the improvements I have made in #37590 and #37597 take the performance penalty on my machine from 40x to 10x. The remaining time is spent in de-duplicating the warning headers and then what remains in encoding and formatting the log message. I don't see any room for improvement on the latter, and the de-duplication is around 50% of the remaining time. I would consider the encoding/formatting the tax we have to pay for deprecation logging something, but there is still room for improvement in the de-duplication.