InvalidConfigurationException when setting confs back to Redpanda

[daisukebe]

Version & Environment

Redpanda version: v21.11.12 (also existing in dev 248e103)

What went wrong?

Kafka clients, e.g. KSQL, that do get the confs from a topic and re-applying the same configuration object to a topic throws the following exception:

Exception in thread “main” java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.InvalidConfigurationException: invalid topic property: redpanda.datapolicy
	at org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
	at org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
	at org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)
	at org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)
	at com.gaincapital.messaging.camel.KafkaAdmin.main(KafkaAdmin.java:30)
Caused by: org.apache.kafka.common.errors.InvalidConfigurationException: invalid topic property: redpanda.datapolicy

This is because Redpanda has our own confs being rejected. Both alterConfig and incrementalAlterConfigs encounter this.

What should have happened instead?

The request should succeeds.

How to reproduce the issue?

1. Get the topic confs via describeConfigs
2. Set it back to the topic via alterConfigs or incrementalAlterConfigs

[ZeDRoman]

I have found out that the problem is how we describe redpanda.datapolicy
Originally we have two parameters for datapolicy: redpanda.datapolicy.function.name and redpanda.datapolicyscript.name
We can set them with alter topic configs.
But in describe topic config we return these parameters as redpanda.datapolicy=function_name: {val} script_name: {val}
That is why after describing config we send alter config request with invalid propery.

Also we ahve two more properties that are described but can't be set in alter_config: partition_count and replication_factor.
We should add these properties to noop list

[ZeDRoman]

/backport v21.11.x