RFR: 8351996: Alternative way to ensure no stale values for ClassValue::remove

[Chen Liang]

The recent patch #23866 violated a long standing contract that calling `ClassValue::remove()` from `ClassValue::computeValue()` should be no-op and exit normally. This behavior caters to a very niche case (why do you remove if you know you are currently computing this item?), but is tested and is required to ensure compatibility.

To resolve the issue found in [JDK-8351045](https://bugs.openjdk.org/browse/JDK-8351045), I discovered that calling `ClassValue::get` between the setup of new input values for `computeValue` and the call to `ClassValue::remove` can serve as a barrier to prevent such a stale value, as described in the `ClassValue::remove` specification:


     * This does not remove the threat of a stale value, since there is a window of time
     * between the return of {@code computeValue} in {@code T} and the installation
     * of the new value.  No user synchronization is possible during this time.


I have added API notes on the method to describe this race and the solution.  The original test to verify the old fix is also updated to use the new call pattern, and indeed the pattern eliminates that race.  Otherwise, the code is effectively reverted to before #23866.

This patch does not intend to undergo CSR review. The usage notes belong to the API notes and don't require a CSR review in theory. Please inform me if you think this needs a CSR.

-------------

Commit messages:
 - 8351996: Alternative way to ensure no stale values for ClassValue::remove

Changes: https://git.openjdk.org/jdk/pull/24043/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351996
  Stats: 93 lines in 2 files changed: 62 ins; 15 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043

PR: https://git.openjdk.org/jdk/pull/24043