[Client] Fix send chunking message failed when ordering key is set.

[Jason918]

Master Issue: #13688

Motivation

The root cause is the same as #13688. Chunking messages share the same metadata. And the type of ordering key is bytebuf, which can not be serialized twice.

Modifications

Reset the field before sending.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• See testChunkingWithOrderingKey

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

Check the box below and label this PR (if you have committer privilege).

Need to update docs?

• no-need-doc
  bug fix

[Jason918]

@gaoran10 @MarvinCai @codelipenghui This is similar to the fix with schemaVersion #12720. PTAL

[Jason918]

/pulsarbot run-failure-checks

[Jason918]

/pulsarbot run-failure-checks

[codelipenghui]

@RobertIndie Please also help review this PR.

[BewareMyPower]

From my perspective, it's so terrible to have all these issues just because all chunks share the same MessageMetadata. I'd like just deep copying this object instead of sharing the object and setting some fields carefully.

I also realized this potential issue when I implement the chunking message feature for C++ client, so I do the deep copy for the initial implementation.

Though for the sake of overhead of bytes copy, this solution looks good. But does it really affect? So I won't approve but I won't request changes as well.

[Jason918]

I'd like just deep copying this object instead of sharing the object and setting some fields carefully.

Yes, it's better to do it this way in the first implementation of chunking.
But before this fix, I have checked all the other bytes field. This is the last one.
And since there is no direct way to deep copy of this protobuffer object.
So I think it's OK to do it by resetting field for now.

[gaoran10]

Lgtm