fix: confusing semantics for ValidatingObjectInputStream

[raboof]

Before Commons IO 2.21.0:

• Rejecting an interface had no effect
• Rejecting a class would reject objects of all subclasses as well
• Accepting an interface had no effect
• Accepting a class would accept objects only if all superclasses were accepted as well

After Commons IO 2.21.0:

• Rejecting an interface had no effect on regular objects, but would reject proxy classes implementing that interface
• Rejecting a class would reject objects of all subclasses as well
• Accepting an interface had no effect on regular objects, but would accept proxy classes implementing that interface
• Accepting a class would accept objects only if all superclasses were accepted as well

That seems rather inconsistent.

The logic change in this PR makes things slightly more consistent, but is a backwards-incompatible change (since it means applications using an allowist but not including the interfaces in it would stop accepting previously-accepted objects).

It seems generally odd that allowlisting a class will not actually accept it without additionally accepting its superclasses (and implemented interfaces).

Perhaps ValidatingObjectInputStream should either not take into account interfaces/superclasses at all, or do so in a more sophisticated fashion.

Before making decisions we should also investigate how JVM11's ObjectInputFilterConfig behaves. That may inform what would make sense for us, and it would be good to document the differences.

Thanks for your contribution to Apache Commons! Your help is appreciated!

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

Hello @raboof
Thank you for the PR.
Many tests fail. You should run mvn before you push to run all build checks.

[raboof]

Well yes it's 'draft' for a reason - this PR is mainly here to start the public conversation on what this should behave like, it's not meant as a finished product yet.