[client][python] Add getLastMessageIdAsync C binding

[komalatammal]

Motivation

Python function getLastMessageId

It is a C binding for #16182 to implement get_last_message_id() in Python client.

Modifications

Add Python/C binding code for get_last_message_id()

Verifying this change

It compiles.

• Make sure that the change passes the CI checks.

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

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: (yes)
• 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

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

• doc
  Python Doc is updated in init.py

• doc-complete
  (Docs have been already added)

[github-actions]

@komalatammal Please select only one documentation label for your PR.
Instructions see Pulsar Documentation Label Guide.

[BewareMyPower]

Could you add a test to pulsar_test.py?

[michaeljmarshall]

LGTM

[michaeljmarshall]

@komalatammal @eolivelli @BewareMyPower - it'd be nice to cherry pick this to 2.11 since it is a feature that is already in the Java client api. Do you think it is too late to get this change into that branch?

[BewareMyPower]

@michaeljmarshall I think it needs a discussion. There was a similar discussion here: #15822 (comment) /cc @nodece

The core question is that should we cherry-pick all these new features of C++/Python clients to release branches?

My personal answer is no. The feature catch up should not be cherry-picked. For the same reason, if users want some new features of a specific component, they have to upgrade the major version.

Regarding 2.11.0 release, I think you can reply in the mail list. I see branch-2.11 has already been created.

[michaeljmarshall]

My personal answer is no. The feature catch up should not be cherry-picked. For the same reason, if users want some new features of a specific component, they have to upgrade the major version.

I agree with this line of thinking. My only reason for asking in this case is because branch-2.11 was only just recently created and the RC has not yet been tagged. I am not going to ask on the ML because I'll just let this target 2.12.

[nodece]

@BewareMyPower @michaeljmarshall Thanks for your explanation! I have a question about the broker and client of old version, if the broker supports the xx feature, but the client doesn't support it, shouldn't we cherry-pick it?

[BewareMyPower]

if the broker supports the xx feature, but the client doesn't support it

IMO no as I've said:

The feature catch up should not be cherry-picked.

[michaeljmarshall]

@BewareMyPower @michaeljmarshall Thanks for your explanation! I have a question about the broker and client of old version, if the broker supports the xx feature, but the client doesn't support it, shouldn't we cherry-pick it?

One reason I think it is unnecessary to backport features to older versions of the client is that the protocol has a feature handshake built in that is supposed to enable different versions of the clients and servers to work together seamlessly. Therefore, if a user wants to get a new feature in the client that was already supported on the broker in an older version, they should be able to upgrade without issue. That being said, I am not sure that we document the client/server compatibility anywhere and I am not sure how good the test coverage is for the many permutations of client versions.

[nodece]

Ok, I see.