[Entitlements] Fix EntitlementInitialization to work across multiple versions

[ldematte]

This PR fixes an issue that become apparent with #121017: when we initialize Entitlements, and we get the list of methods to instrument, and instrument them, we need to get them from all the "versioned" interfaces compatible with the current runtime version. We also need to use the most specific (latest) "versioned" interface in the instrumentation code.

To do that, I cherry picked the changes to EntitlementInitialization in #121017, and adapted it to the current layout in main (where we just support Java >= 21)

[elasticsearchmachine]

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

[ldematte]

@rjernst do we have a better way than hardcoding this here? E.g. some other place where we already have 21 as a minimum supported version?
Also, are we enforcing it, or we allow ES to start even with lower versions? Because if that's the case, we need to change the logic below to always include at least org.elasticsearch.entitlement.bridge.EntitlementChecker, or ES will fail to start on the selfTest().

[mosche]

There's JavaVersionChecker to enforce the minimum version, @ldematte

[ldematte]

Thank you @mosche! TIL
Probably it's OK to have 21 hardcoded here, it's not going to change. I'd hate to add a depdendency just for this :D Wdyt?

[mosche]

yes, agreed, we can't depend on this here 💯

[mosche]

why do we need the lookup on each of the prior interfaces? Isn't the latest sufficient? Especially if using this pattern:

public interface Java23EntitlementChecker extends Java22EntitlementChecker {}

[ldematte]

We examine the class for check$ methods using ASM, which means looking at things class-by-class (it's like looking at the files and reading the methods in the file).
An alternative would be to move the lookup on the ASM side, recursively finding and visiting the base interfaces; that would complicate the ASM code, but might be cleaner.

[ldematte]

It would also cover the case in which we want to "skip" a version, e.g. because we don't want/need to instrment these methods anymore:

public interface Java23EntitlementChecker extends Java21EntitlementChecker {}

(suppose Java22 just contains some preview methods that becomes official in 23, but with a different signature)

[ldematte]

I'm kind of convincing myself that doing this on the ASM side will be a bit more complicated code-wise, but better; wdyt?

[prdoyle]

How would Moritz's inheritance idea work if a method were removed?

[ldematte]

Short answer: the same as this, it does not solve the problem.

Longer answer: it helps in some limited cases/if you structure your interfaces correctly.
Suppose we have a preview feature in Java 22:

public interface EntitlementChecker {}

public interface Java22EntitlementChecker extends EntitlementChecker {
   void check$NewClass$newPreviewMethod(...);
}

Then, the API is finalized in 23 but changes signature wrt 22. We can "skip" Java22EntitlementChecker

public interface Java23EntitlementChecker extends EntitlementChecker {
   void check$NewClass$newMethod(...); 
}

And/or separate interfaces, which is possible to do with inheritance:

interface Java22PreviewMethods {
   void check$NewClass$newPreviewMethod(...);
}

public interface Java22StableMethods extends EntitlementChecker {}

public interface Java22EntitlementChecker extends Java22StableMethods, Java22PreviewMethods {}

public interface Java23EntitlementChecker extends EntitlementChecker, Java22StableMethods {
   void check$NewClass$newMethod(...); 
}

I'm not saying we should do that, it probably does not cover everything, and also would make managing these interface complicated ... I think it would look difficult very fast. It's a possibility though.

[prdoyle]

This prefix logic might need an explanatory comment. It looks a bit random at first glance.

[prdoyle]

We could derive the package name programmatically from EntitlementChecker.class.getPackageName().

[ldematte]

Closing in favor of #121192 (comments addressed there)