Fix @TestTransaction for self-intercepted invocation

[famod]

This caused quite some confusion in my team as all of our test classes using @TestTransaction were working just fine, but for a single one we were getting something like that (this is actually from TestTransactionTest after I extended it):

[ERROR] io.quarkus.it.panache.TestTransactionTest.test2  Time elapsed: 0.006 s  <<< ERROR!
java.lang.IllegalStateException: BaseTransaction.rollback - ARJUNA016074: no transaction!
        at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143)
        at io.quarkus.narayana.jta.runtime.NarayanaJtaProducers_ProducerMethod_userTransaction_c93608e32f9c017c8aafd0401efc2eb68d35aa4e_ClientProxy.rollback(NarayanaJtaProducers_ProducerMethod_userTransaction_c93608e32f9c017c8aafd0401efc2eb68d35aa4e_ClientProxy.zig:197)
        at io.quarkus.narayana.jta.runtime.interceptor.TestTransactionInterceptor.intercept(TestTransactionInterceptor.java:42)
        at io.quarkus.narayana.jta.runtime.interceptor.TestTransactionInterceptorGenerated_Bean.intercept(TestTransactionInterceptorGenerated_Bean.zig:328)
        at io.quarkus.arc.impl.InterceptorInvocation.invoke(InterceptorInvocation.java:41)
        at io.quarkus.arc.impl.AroundInvokeInvocationContext.perform(AroundInvokeInvocationContext.java:41)
        at io.quarkus.arc.impl.InvocationContexts.performAroundInvoke(InvocationContexts.java:32)
        at io.quarkus.it.panache.TestTransactionTest_Subclass.test2(TestTransactionTest_Subclass.zig:459)
        [...]

which is very confusing because on rollback it has no tx anymore?!

Turns out that by blindly calling rollback(), the TestTransactionInterceptor was shadowing the actual problem:

Caused by: java.lang.IllegalStateException: BaseTransaction.checkTransactionState - ARJUNA016051: thread is already associated with a transaction!
        at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.checkTransactionState(BaseTransaction.java:266)
        at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:70)
        ... 106 more

which in turn revealed that the interceptor does not consider self-intercepted invocations of non-private non-test methods from test methods. It was trying to begin a new transaction despite having already done so for the "outer" invocation (the actual test method).

In our case that public helper method was actually an oversight and it should have been private instead. But I don't see why this should be forbidden.
Of course, all this only happens if you use @TestTransaction for the entire test class but IMO that is a good DRY-approach.

TL;DR, this PR:

• adds a check to avoid any subsequent begin() attempts
• fixes exception shadowing
• adds a second test for the "only method annotated case" (I was actually confused why that one test annotated both test class and methods?!)

[quarkus-bot]

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building 69069dd

Status	Name	Step	Test failures	Logs	Raw logs
✖	Native Tests - Windows - hibernate-validator	Build	⚠️ Check →	Logs	Raw logs

[quarkus-bot]

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building c3231c5

Status	Name	Step	Test failures	Logs	Raw logs
✖	Native Tests - Windows - hibernate-validator	Build	⚠️ Check →	Logs	Raw logs

[famod]

I decided to handle Error as well, mainly so that the interceptor does not shadow AssertionErrors when something goes wrong when rolling back (mostly a theoretical problem, but you never know).

[quarkus-bot]

Failing Jobs - Building 3370b6f

Status	Name	Step	Test failures	Logs	Raw logs
✖	Native Tests - Windows - hibernate-validator	Build	⚠️ Check →	Logs	Raw logs