Deprecate use of htmlStrip as name for HtmlStripCharFilter

[cbuescher]

The camel case name htmlStip should be removed in favour of html_strip, but
we need to deprecate it first. This change adds deprecation warnings for indices
which are create after 6.3.0 and logs deprecation warnings for these.

[cbuescher]

I'm not 100% sure this is the best place to actually issue a deprecation warning for a deprecated analysis component name, I was e.g. suprised that this will trigger a warnign for each index request to a new index that uses an analyzer with the deprecated name (see rest test). Happy to discuss any other options.

[mayya-sharipova]

@cbuescher What do you think of the approach to issue a deprecation warning when a request with htmlStrip is processed, something like: https://gist.github.com/mayya-sharipova/27cdcdc427327235d126c11280ee01ba?

I am also wondering what happens in the next version that will not have these deprecations, and an index still contains htmlStrip as a char filter?

[romseygeek]

cc @elastic/es-search-aggs

[cbuescher]

@mayya-sharipova sorry for the long silence of this, I took a look at your suggestion. What I like about wrapping the deprecation logging inside the PreConfiguredCharFilter#create function is that we can log deprecation warning based on index versions, so using the old filter name in old indices shouldn't have any effect. What I still don't like about my current solution is that for new indices we add warning headers to each request. The deprecation log itself should be fine because DeprecationLogger#deprecatedAndMaybeLog should supress most duplication, but it seems like we create a new HTMLStripCharFilter for each new token stream.
I spent some time looking for a good place to emit the warning only once on new index creation, but couldn't find any so far. Maybe @jpountz has a suggestion?

[jpountz]

I spent some time looking for a good place to emit the warning only once on new index creation, but couldn't find any so far. Maybe @jpountz has a suggestion?

Analysis components should be cached per thread, so these warnings should stop after the analyzer has been used in every thread of the index/search threadpools. I think your approach is fine.

[cbuescher]

I think your approach is fine

@jpountz thanks, I was also thinking about the client side which will get warning headers back with every request I think, that isn't de-duplicated like the in the deprecation logs. But I also guess that is something the client can ignore easily usually. Will keep this open for a bit but will merge later if there are no other objections.
Another thing, I haven't labeled it yet with 6.x but already use the 6_3_0 version in the PR, so I was planning to backport this. Is that okay too or does this requiere any additional notes in the migration docs etc? I checked an we don't advertise the htmlStrip name in any docs at least since 5.6 (maybe even longer), so most ppl. should be using html_strip anyway, wdyt?

[jpountz]

I was also thinking about the client side which will get warning headers back with every request I think

Is it true? Token filters are supposed to be cached per thread, so after some requests, there should not be any warnings in the headers anymore?

I think we should only add it to the migration notes of 7.0, when the camelcase alias gets removed.

[cbuescher]

Is it true? Token filters are supposed to be cached per thread, so after some requests, there should not be any warnings in the headers anymore?

I think so, thats at least how I interpret the Yaml Rest test that I added in this PR. Adding two documents to the index that uses the old deprecated name issues warning headers twice. I suppose the reason is because the response headers are added here regardless of how the boolean "log" flag that is used for de-duplication is set. In a way it makes sense: while one warning in the logs should usually be enough to warn admin-type users, clients could be different and if we only warn once the second user that should get that warning doesn't see it anymore.
Maybe I'm also misinterpreting this, will try using curl quickly.

[cbuescher]

Token filters are supposed to be cached per thread

Turns out the repeated warning headers in the responses are expected since this is a char filters as opposed to tokenizers or token filters, which are cached differently.
We cannot really avoid the warning headers in the rest responses here, but the deprecation warning will be logged only once (or at last infrequently) and the response headers can easily be ignored.