I ported some 20 year old tests using JDK-8262881 in order to help
test [~rehn]'s fix for JDK-8257831. These tests in combination with
one piece of the fix from JDK-8257831 revealed a bug in my fix for
JDK-8258284 from back in Dec 2020.

The race revealed by the ported tests from JDK-8262881 happens
only with nested ThreadsListHandles. When TLH2 is destroyed, the
thread updates its threads_hazard_ptr from the TLH2-list to the
TLH1-list; I made this change back in 2020.12 using JDK-8258284.
The threads_hazard_ptr can be observed by a thread calling
ThreadsSMRSupport::free_list() as a stable ThreadsList at the same
time as the TLH1 destructor is decrementing the nested_handle_cnt
that permits the ThreadsList to be freed. So the thread calling
ThreadsSMRSupport::free_list() thinks it has a stable hazard ptr
(TLH1-list), but that hazard ptr can be freed and causes lots of
confusion.