add test ensuring PainlessPlugin#baseWhiteList() remains stable-API

[yaauie]

A recent refactor in #106913 introduced PainlessPlugin#baseWhiteList() and removed PainlessPlugin.BASE_WHITELISTS, which caused builds of Logstash's Elastic integration plugin to break when run against Elasticsearch main (elastic/logstash-filter-elastic_integration#135).

Since we need an API-stable way of getting the plugin's default whitelists, here we add a test to document its use and ensure it remains API-stable. We also backport this test to the 8.13 series along with an implementation that falls through to the existing static field in #107120 so that our builds will succeed between now and when 8.14.0 is released.

---

Perhaps worth noting, the method introduced in #106913 in returns List<Whitelist>, but is named in a way that mismatches in two ways:

• the method name is singular, even though it provides a List
• the method name has superfluous capitalization WhiteList while the contents are a Whitelist

We may want to remedy this mismatch before marking the method as API-stable.

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[dakrone]

@yaauie I thought when we ran into this last time we agreed that for things where we required a non-breaking stable API, we'd put that into the Logstash plugin layer, similar to what we did in #105163?

[yaauie]

@dakrone the existing LogstashInternalBridge is a part of org.elasticsearch.ingest, which is not dependent on org.elasticsearch.painless and therefore can't reference bits that we need.

[williamrandolph]

Looks good to me.

I'd also support changing PainlessPlugin#baseWhiteList to PainlessPlugin#baseWhitelists or PainlessPlugin#getBaseWhitelists. How complicated will that be for the downstream dependency?

[yaauie]

I'd also support changing PainlessPlugin#baseWhiteList to PainlessPlugin#baseWhitelists or PainlessPlugin#getBaseWhitelists. How complicated will that be for the downstream dependency?

If it happens before we rely on it, easy peasy (needs to be reflected in 8.13 series too), but if it happens after then things get messy.

[rjernst]

While I understand the intention, I do not think adding a test in this way will prevent such a future breakage. We use code refactoring tools to make such changes, where it is likely we won't even notice the test.

Ultimately no Java code in Elasticsearch is stable (with the exception of the stable plugin api). Trying to force some stability on small parts of our internal APIs is likely to continue to cause friction.

If Logstash needs a stable way to access some internals, I suggest another gradle project within server that has the appropriate dependencies, and presents its "stable api". This would be very similar to the existing LogstashInternalBridge (I would even move that bridge to the new project. By keeping it in the Elasticsearch codebase, such future refactorings will be automatically handled if done through IntelliJ, or the use site will be necessarily adjusted to keep the ES build working. The only caveat is this should not be published to maven; we don't want to give the perception that such an api is stable for uses outside of Logstash.