KAFKA-14405: Log a warning when users attempt to set a config controlled by Streams

[shashankhs11]

This PR addresses KAFKA-14405 JIRA and builds upon significant work done from #12988.

Initial Problem

It's too easy for users to try overriding one of the client configs that Streams hardcodes, and since we just silently ignore it there's no good way for them to tell their config is not being used. Sometimes this may be harmless but in cases like the Producer's partitioner, there could be important application logic that's never being invoked.

When processing user configs in StreamsConfig, we should check for all these configs and log a warning when any of them have been set

New Problem

During the work in #12988, it was found that -

• Users could bypass Kafka Streams' controlled configurations by using specific consumer prefixes (e.g., main.consumer.allow.auto.create.topics=true instead of consumer.allow.auto.create.topics=true).
• Similar bypasses existed for global consumer and producer configurations Confirmed here
• Root cause of bypass here

Summary of Work from previous PR

• New configuration architecture separating "defaults" vs "controlled" configs. More details can be found in this review comment
• There was also a discussion to handle ProducerConfig.PARTITIONER_CLASS_CONFIG. But this needs a KIP as per the discussion here

Pending Work

• A few more configs need to be covered; group.id, client.id, client.instance.id, auto.offset.reset as per this review
• More test cases need to be written to cover the current changes and upcoming changes

Question - I wanted to ensure if this looks good before I proceed to cover the Pending Work section OR do we need a new PR for the other configs (apart from tests)?

[shashankhs11]

Tagging @mjsax and @ableegoldman, requesting to review whenever you get a chance, as you both were involved in reviewing the previous PR, which unfortunately wasn’t merged.

[github-actions]

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.