docs: klip-67: Make internal topic prefix configurable

[ocadaruma]

Description

• Propose KLIP-67
  • Related issue: Internal topics prefix and name configurable  #4954

Testing done

• N/A

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[colinhicks]

Thanks for the thoughtful PR, @ocadaruma. While the reasoning outlined in your proposal makes sense, I have some concerns. A broad surface area of the product relies on the internal-topic naming convention. Allowing it to be user-configured would yield implications and risks for data isolation, compatibility, and security.

Beyond the config and command_log topics you mentioned, the current naming convention applies to other internal resources, including changelog topics.

Because these internal topics are used as durable storage, their names are not expected to change during a KSQL cluster's lifecycle. If the value of the proposed new configuration were changed to a new prefix, it seems there would need to be a migration of data and state from topics with the previous naming convention. There's a similar consideration for access control: If the internal topic prefix changes, what would be the expectation for the respective ACLs that need to transition from the old to new prefix?

[ocadaruma]

@colinhicks Thanks for taking a look.

the current naming convention applies to other internal resources, including changelog topics.
...Because these internal topics are used as durable storage, their names are not expected to change during a KSQL cluster's lifecycle.

I think similar implications as ksql.service.id applies.
ksql.service.id is already used in command topic and changelog topics to isolate KSQL deployments, and it's not expected to be changed over entire KSQL lifecycle.

So the new customizable internal-topic name prefix also treated similarly. It's not expected to be changed once deployed.

Hmm, maybe there are several documentations necessary to be updated in addition to server-configuration.md (most relevant one seems to be this section: https://github.com/confluentinc/ksql/blob/master/docs/operate-and-deploy/installation/server-config/security.md#acls-on-prefixed-resource-pattern in terms of ACL)