[#1862] [3.0] Support for JDK 25 scoped values

[lprimak]

…Local

Allows for graceful fallback to ThreadLocal if something goes wrong

Following this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a GitHub issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a GitHub issue. Your pull request should address just this issue, without pulling in other changes.
• Format the pull request title like [#XXX] - Fixes bug in SessionManager,
  where you replace #XXX with the appropriate GitHub issue. Best practice
  is to use the GitHub issue title in the pull request title and in the first line of the commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• add fixes #XXX if merging the PR should close a related issue.
• Run mvn verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
• Committers: Make sure a milestone is set on the PR
• Committers: Use "Squash and Merge" to combine all commits into one when merging a PR when appropriate.

Trivial changes like typos do not require a GitHub issue (javadoc, comments...).
In this case, just format the pull request title like [DOC] - Add javadoc in SessionManager.

If this is your first contribution, you have to read the Contribution Guidelines

If your pull request is about ~20 lines of code you don't need to sign an Individual Contributor License Agreement
if you are unsure please ask on the developers list.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
• In any other case, please file an Apache Individual Contributor License Agreement.

[bmarwell]

Some MR-JAR hints (can create a PR to this branch if you like).
But in general: Does it work with a utility class like this? If so, this would be great for migration to Scoped Values :)

[lprimak]

@bmarwell I have refactored the code into interfaces, like you suggested. Thank you!
Can you please re-review?

[lprimak]

@boris-petrov Can you please review this please?

[boris-petrov]

I haven't looked in details at the implementation but wouldn't it be better if there were a couple of new classes like ScopedValuesCallable and ScopedValuesRunnable which would extend SubjectCallable/SubjectRunnable (or perhaps even directly Callable/Runnable)? And then at the instantiation site choose which one is appropriate? Not sure if that would make sense and if it would make the code "better"?

[lprimak]

Thanks for the review, @boris-petrov
What you are suggesting was my first thought, but unfortunately it really didn't wind up having advantages, just disadvantages.

The main issue here is that ScopedValues is not really a polymorphism and shoehorning strategy pattern only made things worse.

[boris-petrov]

So it's great then! Do you think it would be easy/possible to back-port this to Shiro 2.x?

[lprimak]

Possible... but thing like that are "enterprise feature" IMHO

[lprimak]

@bmarwell you are the only reviewer left :)