[fix][client] Preserve equals in FieldParser map values

[hiSandog]

Fixes: none

Motivation

FieldParser parses map configuration values by splitting every = character. This rejects values that contain = and also rejects empty string values such as key=, even though both are valid string map values after the first key/value separator.

Modifications

Split map entries on the first = only, preserving the rest of the value. Added a regression test covering a value that contains = and an empty map value.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• Added FieldParserTest.testMapWithEqualsSignAndEmptyValue
• Ran git diff --check
• Attempted ./gradlew :pulsar-common:test --tests org.apache.pulsar.common.util.FieldParserTest, but the local environment has no Java Runtime installed, so Gradle could not start.

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

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

[lhotari]

FieldParser parses map configuration values by splitting every = character. This rejects values that contain = and also rejects empty string values such as key=, even though both are valid string map values after the first key/value separator.

@hiSandog do you have some Pulsar use case to share where this issue came up?

[hiSandog]

Thanks for asking. I do not have a production incident to point to here; I noticed the edge case in FieldParser itself. A representative case is a string map config value that carries an encoded token, query fragment, or base64-style padding, where the value contains '=' characters, for example token=abc==. Splitting only on the first '=' preserves that value, and it also keeps key= as an explicit empty-string map entry instead of rejecting it.

[lhotari]

Thanks for asking. I do not have a production incident to point to here; I noticed the edge case in FieldParser itself. A representative case is a string map config value that carries an encoded token, query fragment, or base64-style padding, where the value contains '=' characters, for example token=abc==. Splitting only on the first '=' preserves that value, and it also keeps key= as an explicit empty-string map entry instead of rejecting it.

Thanks for sharing, this is very useful context. Please add it to the PR description too.

[lhotari]

LGTM, thanks for contributing @hiSandog