[fix] [broker] No longer allow creating subscription that contains slash

[poorbarcode]

Motivation

Topic name rule

• old version: {tenant}/{cluster}/{namespace}/{topic}/{subscription}
• new version: {tenant}/{namespace}/{topic}/{subscription}

There are many HTTP APIs defined as HTTP Method {topic name}/{subscription name}

If a subscription contains /, the broker will assume it is a topic created with the old rule, then users will get a cluster does not exist error or a topic not found error

Modifications

No longer allow creating a subscription that contains a slash

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository: x

[gaoran10]

LGTM.

Do we need to support decoding URL-encoded subscription names in broker side? Thus users can use existing URL-encoded subscription names in HTTP requests.

[zjxxzjwang]

Can you put it into a method to facilitate the extension of more subscription name restrictions in the future

[Shawyeok]

HTTP Method {topic name}/{subscription name}

The subscription name should be URL-encoded. For example, to create a subscription a/b for the topic persistent://public/default/topic1, the request should be:
PUT /admin/v2/persistent/public/default/topic1/subscription/a%252Fb.

I believe pulsar-admin and pulsarctl already handle this properly.

I appreciate the approach of restricting naming conventions for subscription and topic names. In my organization, subscription names are limited to the following characters: a-zA-Z0-9.-_.

[lhotari]

Related PR: #23620

[lhotari]

I appreciate the approach of restricting naming conventions for subscription and topic names. In my organization, subscription names are limited to the following characters: a-zA-Z0-9.-_.

@Shawyeok There's an enhancement issue #23614 created by @alpreu to add validation to subscription names.

[lhotari]

It looks like PR #23620 could be an effective way to prevent the auto creation of topics with slashes.

I think that we should consider implementing #23614 to validate subscription names instead of preventing the creation of subscription names with slashes.

As pointed out by @Shawyeok in #23594 (comment), if a slash is included in the subscription name, it should be url encoded. That's why this PR doesn't make sense to me and I'd prefer #23620 as the solution.

[poorbarcode]

@lhotari

I think that we should consider implementing #23614 to validate subscription names instead of preventing the creation of subscription names with slashes.

But should we prevent the creation if the result of the validated subscription name is false?

Sent a discussion to do that

• https://lists.apache.org/thread/j8shr3wqr1xdv3rxpth2f53ctnzc1ny1

[lhotari]

Sent a discussion to do that

• https://lists.apache.org/thread/j8shr3wqr1xdv3rxpth2f53ctnzc1ny1

@poorbarcode I think it makes sense to reference #23614 and #23620 in the discussion since those describe useful solutions. They are addressing 2 separate issues.