Ingest geoip processor cache 'no results' from the database

[joegallo]

For my own future reference, here's some history of the geoip cache: it was originally added in #22231, rewritten for better performance in #33029, and tweaked for better performance in #80737 and #92372.

The maxmind DatabaseReader's tryCity/tryCountry/tryAsn methods return an empty Optional if you ask about an ip address for which the database doesn't have a record, and we very quickly convert that into a null value (see DatabaseReaderLazyLoader#getResponse).

Externally, the cache has two way logic: it either returns a response if there was one, or it returns null if there's nothing in the database for that ip address. That was true before this PR, and it remains true after this PR.

Internally, the cache used to have two way logic: it would A.) return a result from the cache if there was one, OR B.) it would hit the underlying database if it had either never seen the ip address before or if the ip address wasn't in the database.

After this pull request that logic changes to three way logic: it will A.) return a result from the cache if there is one, OR B.) return null 'from the cache' if there isn't a record of the ip address in the database, OR C.) hit the underlying database if it hasn't seen the ip address before.

Generally speaking, I don't expect the databases to have records for "private internets" (https://www.ietf.org/rfc/rfc1918.txt) so if you're feeding a lot of those sorts of ip addresses into the geoip processor, then this change will result in significantly better performance for you (since we'll cache 'no-result' rather than hitting the underlying database each time).

In some ad-hoc testing on my machine, a cache hit is about an order of magnitude cheaper than hitting the actual database, so the more we can exercise the cache, the faster we'll be.

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[elasticsearchmachine]

Hi @joegallo, I've created a changelog YAML for you.

[masseyke]

I'm a little nervous about unintended side effects, but it definitely makes sense that we'd want to cache cache misses. And if due to some weird distribution of data a user finds themselves now getting 0 cache hits (and they probably weren't getting many cache hits before), they can can increase their cache size and/or start mapping their invalid IP addresses to something valid in a step before the geoip processor.