_timestamp and _ttl still use legacy numerics

[jpountz]

I just noticed that _timestamp and _ttl still use legacy numerics. We need to either forbid them on new indices (since they were deprecated in 2.0) or make them use points.

It is not strictly required to do it before 5.0 but that would be much better if 5.0 never created fields with legacy numerics.

[jpountz]

For the record, we had a quick chat with @rjernst about moving those to plugins, but it would require adding pluggability to the parsing of request parameters and the translog, which is probably something that we want to avoid (especially the latter).

[clintongormley]

The _timestamp and _ttl fields were deprecated in 2.0.0-beta1 because they are problematic:

• what does the _timestamp represent? a created date or a last-modified date or some other timestamp value?
• should the _ttl be extended on update? what if an update happens after expiry?

etc etc. There are no right answers to these questions - they depend entirely on use case. Instead of providing these "opinionated features", we'd be better of just providing the primitives required for users to implement the logic they need.

We have these primitives in 5.0: ingest pipelines allow injecting a new timestamp at index time, delete-by-query is being moved back into core (#16883) for deletion of expired documents, and the update API allows updating the ttl and timestamp as the user sees fit.

We still need to be able to support indices created in 2.x in 5.x, but we should prevent new indices from enabling _ttl and _timestamp.

[clintongormley]

Would be good to add deprecation logging in 2.x