MINOR: Refactor DelegatingClassLoader to emit immutable PluginScanResult

[gharris1727]

The DelegatingClassLoader has a large number of fields and methods for keeping track of known PluginDesc objects. It has this in common with the PluginScanResult data object, which has a similar set of fields and methods. On trunk, the PluginScanResult is only used as a return value of one internal function, before it's results are accumulated by the DCL and discarded. To simplify the DCL, we should use the PluginScanResult object as a container to store and accumulate PluginDesc objects, and return it to the caller to allow them to inspect the scanned plugins without interacting with the DCL.

Using the PluginScanResult as an accumulator, we can delay writing scan results to the pluginLoaders and aliases fields until after all scanning has taken place. This is done via the new installDiscoveredPlugins method. This prevents plugins being scanned from having an inconsistent delegation path: Previously, because the accumulators were updated as scanning proceeded, plugins may or may not be able to see one another via the DelegatingClassLoader::loadClass method. Now, plugins will not be able to see one another before installDiscoveredPlugins is applied and scanning is finished.

This is a first-pass refactor, before pulling the scanning logic out of the DCL to further simplify it. Once external scanning is complete, the caller will call installDiscoveredPlugins to finish initialization of the DCL.

In the trunk implementation, there is some order-sensitivity to the scanning process because of the accumulator fields. In particular:

1. Because the classpath is scanned last, plugins on the classpath automatically take precedence over isolated plugins. In order to replicate this effect, PluginDesc objects now explicitly compare their isolated/non-isolated nature, and order classpath plugins first.
2. The alias mechanism attempts to determine if aliases are unique, but on trunk it allows colliding aliases from different plugin types to overwrite one another. This is changed to prevent alias collisions across plugin types, now that the iteration over PluginDesc objects isn't grouped by plugin type.

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)

[C0urante]

Thanks Greg. Some minor stylistic comments. Also not sure we should be modifying the aliasing logic without a very good reason; let me know if there's implications that I'm missing.

[C0urante]

Thanks Greg! I think the tradeoffs here are acceptable. Can we add some testing coverage for PluginUtils::computeAliases? Once that's done this should be good to merge.

[gharris1727]

Here's an example of the new log message, pulled from the test run:

[2023-06-02 10:15:57,932] WARN Ambiguous alias 'Colliding' refers to multiple distinct plugins [org.apache.kafka.connect.runtime.isolation.PluginUtilsTest$CollidingHeaderConverter, org.apache.kafka.connect.runtime.isolation.PluginUtilsTest$CollidingConverter]: ignoring (org.apache.kafka.connect.runtime.isolation.PluginUtils:378)

[C0urante]

Thanks Greg! Really appreciate the added testing coverage for alias computation. Some small test comments and one logging suggestion and then this should be good to go.

[C0urante]

Thanks Greg! LGTM

Will merge pending CI build

[C0urante]

@gharris1727 there are test failures in the latest CI run. Can you look into those? Feel free to just rebase on the latest trunk if that's all that's required.

[C0urante]

Test failures appear unrelated (there is a known bug in the reflections library that we use that caused a test failure which may appear related, but is not). Merging...