FELIX-6871 Release the class lock when another thread defined the class first

[RefuX]

Fixes FELIX-6871.

BundleWiringImplTest.defineClassParallelReleasesItsLockWhenTheClassIsAlreadyDefined takes the late thread's path on a single thread, so its result is deterministic. It defines a class through findClass, calls defineClassParallel again for the same name, and asserts that the same Class comes back and m_classLocks is empty. Without the fix it fails:

Expecting empty but was: {"org.apache.felix.framework.BundleWiringImplTest$TestClass"=Thread[#1,main,5,main]}

[paulrutter]

Thanks for the fix. I traced defineClassParallel and the root cause is right. putIfAbsent in the loop condition can return null (this thread took the lock) and the body then finds the class. The loop exits with clazz != null and the finally that removes the lock is skipped, so the entry (and its Thread) leaks.

remove(name, me) is the correct release here. It cannot drop another thread's entry. It also cannot drop an outer re-entrant entry of the same thread: in that case the first putIfAbsent returns me, the loop exits with clazz == null, and the else branch is never reached.

No blocking issues. Three optional follow-ups are in the inline comments:

• Release consistency: the finally still uses the unconditional remove(name).
• Test coverage: nothing covers the case where another thread owns the lock.
• Test setup: it duplicates findClassExistant.