[Fix][Flaky-test] Fix testConsumeTxnMessage

[liangyepianzhou]

Fixes #14109

Motivation

The transaction commit is async, so the consumer can still receive message when the consumer rebuilds.

Modification

Add Awaitility.await() for check-ing whether the ongoingTxns = 0.

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If yes was chosen, please highlight the changes

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API: (yes / no)
• The schema: (yes / no / don't know)
• The default values of configurations: (yes / no)
• The wire protocol: (yes / no)
• The rest endpoints: (yes / no)
• The admin cli options: (yes / no)
• Anything that affects deployment: (yes / no / don't know)

Documentation

Check the box below or label this PR directly.

Need to update docs?

• doc-required
  (Your PR needs to update docs and you will update later)

• doc-not-needed
  (Please explain why)

• doc
  (Your PR contains doc changes)

• doc-complete
  (Docs have been already added)

[codelipenghui]

@liangyepianzhou Do you see consumer reconnection logs? Yes, the change may be can resolve the flaky test, but it will also hide a potential BUG of message duplication.

[codelipenghui]

We should consider checking if the consumer is reconnected to the broker, if yes, the message duplication is expected. Otherwise, we should not receive duplicated messages.

[liangyepianzhou]

The consumer will reconnect and the message duplication is not expected.
We produce 505 messages.
The PerformanceConsumer will ack the messages (0-500) with the transactions and then commit the transactions.
When the consumer reconnects, we hope only the messages (501-505) can be received.
Because the transaction commit is async, the last transaction may not have been committed.
And then the consumer will receive message (400 - 505).

[codelipenghui]

Because the transaction commit is async, the last transaction may not have been committed.

So, we should fix the test to make sure the consumer start to consume messages after confirm the last transaction has committed?

[liangyepianzhou]

Because the transaction commit is async, the last transaction may not have been committed.

So, we should fix the test to make sure the consumer start to consume messages after confirm the last transaction has committed?

Right, but we don't know when the last transaction was committed.

[codelipenghui]

Right, but we don't know when the last transaction was committed.

Can we check through the TC stats? As I said, the change will hide the BUG that introduced the message duplication issues. If we don't have a way to check if the last transaction is committed, we should add it.

[Jason918]

This PR depends on #15675 which is not included in branch-2.10. so remove release/2.10.2