Fix commit after statement fail in non-autocommit transaction

[hantangwangd]

Description

Following PR #23247 , this PR handle the session corruption cause by a failed statement in non-autocommit transaction as well.

When executing commit in above scenario, it should fail while aborting the whole corrupted transaction successfully. Thus we can keep running following statements within the same session.

Motivation and Context

Fix: #23246

Test Plan

• Newly added test cases in AbstractTestDistributedQueries to simulate the scenarios described in Session is completely corrupted by the failed statement in a non-autocommit transaction #23246
• Manually confirm the fix in CLI console

Contributor checklist

• Please make sure your submission complies with our contributing guide, in particular code style and commit standards.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

== RELEASE NOTES ==

General Changes
* Fix COMMIT statement to ensure it successfully abort non-auto commit transactions corrupted by failed statements

[ZacBlanco]

Changes look good. I have a question about the tests

[ZacBlanco]

Can we still call rollback here before or after this query? Can we add that to verify what the comment above states?

[hantangwangd]

After this statement, the transaction is completely aborted. So, if we calling ROLLBACK again, the behavior should be the same as when no transaction was started at all, and an error message will be reported as follows:

Query xxx failed: No transaction in progress

In CLI console, it indeed behavior as above. However, currently in the testing framework, since the flag clearTransactionId cannot be returned to the client's session, executing rollback again will report the following error message:

Expected exception message 'Unknown transaction ID: cddea4f9-4dd9-437f-bab5-0cc17c76dee5. Possibly expired? ...

Now I have added all these scenarios to the test case. I thinks this failure message can demonstrate that the transaction has been aborted by the server.

[ZacBlanco]

Just so I understand what this PR fixes: Before this change, would this query have failed due to the previous transaction failure?

[hantangwangd]

Yes, before this change, the query would always fail after a transaction is corrupted by previous failure. However, the test framework can't accurately mimic the real world behavior, so in the test case transaction(...).execute(...) itself will finally fail because of the corrupted transaction if we didn't abort it properly.

I have refactored the test case and added some comments to clarify the expected behaviors of subsequent statements. Please take a look when available, thanks.