[improve][txn] Add getState in transaction for client API

[congbobo184]

Motivation

now org.apache.pulsar.client.api.transaction.Transaction dont have a interface for user to get the transaction state.

user can get the transaction state to do user's own op.

Modifications

1. add the interface in org.apache.pulsar.client.api.transaction.Transaction getState
2. TransactionImpl implement the interface

     * Get transaction state.
     *
     * @return {@link State} the state of the transaction.
     */
    State getState();

Verifying this change

add the test

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): (no)
• The public API: (no)
• The schema: (no)
• The default values of configurations: (no)
• The wire protocol: (no)
• The rest endpoints: (no)
• The admin cli options: (no)
• Anything that affects deployment: (no)

Documentation

• Does this pull request introduce a new feature? (yes)

• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

• If a feature is not applicable for documentation, explain why?

• If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

• doc-not-needed

[codelipenghui]

I hope it can be cherry-picked to release branches from branch-2.9.
So that users can use the new method to check the transaction state.
And the change will not introduce risk to release branches.

[codelipenghui]

@Anonymitaet Please help review the Java Doc

[Anonymitaet]

Feel free to correct me if my understanding is inaccurate, thanks!

[congbobo184]

@Anonymitaet @codelipenghui I have fixed the comments, please review again. Thanks! :)

[Anonymitaet]

Thanks for your contribution! Approved from a technical writing perspective. 😊

[nicoloboschi]

@congbobo184 would you mind to explain a case where the user needs to know the state of the transaction object? could you explain what are the actions they can take based on the state?

I'm ok with the pull itself but since we're adding it to the public API (and maintain it forever even if the internal transaction mechanism changes) we need a strong reason

[codelipenghui]

@nicoloboschi I see a transaction production user. They are using TransactionImpl.checkIfOpen() to do some checks when they using transactions. Otherwise, they can only do it by catching exceptions, but it's a bad experience. The ideal case is users don't need to care about the transaction state, just commit it or abort it. Always under some complex use cases, users depend on the state check (same as client.isConnected(); consumer.isConnected();)

[Technoboy-]

Cherry-picked by #19834