CASSANDRA-21525 4.0 - Verify extension type before initializing reflectively-loaded classes

[smiklosovic]

Cassandra resolves pluggable extensions by class name from configuration, schema, and tooling inputs. These names were loaded with an initializing Class.forName(name) and type-checked only afterward, so the named class ran its static initializer before its type was confirmed. After this change such classes will be loaded without initialization, verified against the expected interface or base class, and initialized only through normal use after validation.

A shared FBUtilities.classForNameWithoutInitialization helper and typed instanceOrConstruct/construct overloads apply this to the configurable extension points loaded by class name: the authentication, authorization, role-management, network and internode-authenticator backends, the partitioner, audit logger, configuration loader, seed provider, snitch, abstract types, secondary and custom indexes, compaction strategy, compressor, replication strategy, SASI analyzers, key and cache providers, query handler, storage and stream hooks, tracing, the JMX authorization proxy, MBeans, the monotonic clock, nodetool Sjk, triggers, the sstableloader and stress class options, and diagnostic event classes (loaded without initialization and checked against DiagnosticEvent, preserving the InvalidClassException contract and the existing package restriction).

Regression tests confirm that an invalid-type load is rejected without initializing the target class, and that valid implementations still resolve.

Hadoop client integration and hard-coded JDK and internal class probes are left unchanged.

patch by Jeremiah Jordan; reviewed by for CASSANDRA-21525

Thanks for sending a pull request! Here are some tips if you're new here:

• Ensure you have added or run the appropriate tests for your PR.
• Be sure to keep the PR description updated to reflect all changes.
• Write your PR title to summarize what this PR proposes.
• If possible, provide a concise example to reproduce the issue for a faster review.
• Read our contributor guidelines
• If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:

<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira