Issue #24805 Make ConnectionPool code more strict and do not return Enlisted resources

[escay]

Make ConnectionPool code more strict and do not return Enlisted resources.

Throw isBusy and enlisted IllegalArgumentExceptions on purpose in the goal to find out why #24805 sometimes occurs.
This allowed me to see ConnectionPool.internalGetResource skip getResourceFromTransaction logic in some cases, and then calling getUnenlistedResource returned an Enlisted resource.

Therefor adding logic:
Add new isEnlisted logic in the getResourceFromPool method to possibly fix #24805 Remove getMatchedResourceFromPool method. Status is: passes all 209 "./runtests.sh jdbc_all" tests.

Also refactored some old TODO statement: replace getMatchedResourceFromPool implementation with a call to getResourceFromPool.

[OndroMih]

Running the Jakarta EE TCK here (with master merged): https://ci.eclipse.org/jakartaee-tck/job/10/job/eftl-jakartaeetck-run-100/295/ - 👍 passed
Running the standalone Jakarta EE TCKs: https://ci.eclipse.org/jakartaee-tck/view/EFTL-Certification-Jobs-10/job/eftl-jakartaeetck-run-standalone/163/ - 👍 passed

[dmatej]

Is there a reason why is this still in a Draft mode?

[escay]

@dmatej Just discussed the reason today in #24805 latest comments.
This fix prevents the problem from occurring, as shown in the integration test.
But I wonder if it should be supported, or that the fix should be: throw an exception, or log a warning.
Last month I have been testing without the fix by changing my application code, this now runs stable when I do not expose a Connection from one bean method to another bean method. Question is: should exposing a Connection be allowed? If this should be allowed then I can remove the draft mode. If it should not be allowed I would opt for logging a warning + this fix.

[escay]

Changed to ready for review. Assuming now that exposing a Connection from one bean method to another bean method should be possible.