Add `_terms_enum` support for the `ip` field type

[Dosant]

Description

Description

The _terms_enum API currently supports keyword, constant_keyword and flattened fields.

Kibana would also like to support ip field type: elastic/kibana#140266
Opening this issue to discuss if this is possible.

I tried to workaround this limitation in Kibana using terms_agg for suggestions, but this also didn't work:
elastic/kibana#140266 (comment)

Note: there is a similar issue and some progress on version type: #83403

[elasticsearchmachine]

Pinging @elastic/es-search (Team:Search)

[rockdaboot]

The profiling team needs this to solve elastic/kibana#140266.

Customers will insert billions of extra fields (additional fields with the string representation of ip fields) as a work around. See https://github.com/elastic/prodfiler/issues/2782.

Can we somehow prioritize this issue ?

[rockdaboot]

Gentle ping 😃

[cbuescher]

@rockdaboot I took a look into this today. The situation is a bit different than with the version field (#83403). That field type was intended and implemented as a specialization for the keyword field type with the only difference that it has a sort order that takes semantic versioning ordering into account.
The ip field is different in that it doesn't have a text representation once we store it. Its internal representation as points is optimized for fast range queries, in contrast it doesn't come with support for typical string-type operations like prefix queries. For that reason I'm currently not convinced if we can get the same performant response out of this field type for _terms_enum that we get for string-type fields, but I will investigate.

A question I have is around the intended behavior for the prefix filtering. Should the prefix string provided with the terms_enum request be considered a string prefix for the ips to be returned or e.g. the leading octet(s)? i.e., for a prefix with "10" would you expect "10.0.0.0" and "100.0.0.0", "101.0.0.0" etc... to be returned or just the "10.0.0.0" address. I personally would expect the former type-ahead behavior, but your expectations for usage in KQL might be different.

[rockdaboot]

Thank you for looking into this @cbuescher !

We currently just want to have auto-suggestion for IP fields (see elastic/kibana#140266). The way we implement it is by storing the string representation of the IP in a second field host.ipstring and tell the user to use this in KQL instead of using host.ip directly. This leads to confusing situations; the UX could be better =).

So it would be perfectly fine to use a string prefix (as we do now), e.g. "10" means "10.0.0.0" as well as "100.0.0.0" and "101.0.0.0" (taken your examples).