Major Description
Right now Kafka consumer protocol uses a singleton marker to distinguish Kafka Connect worker and normal consumer. This is not upgrade-friendly approach since the protocol type could potential change over time. A better approach is to support multiple candidacies so that the no downtime protocol type switch could achieve.
For example, if we are trying to upgrade a Kafka Streams application towards a protocol type called "stream", right now there is no way to do this without downtime since broker will reject changing protocol type to a different one unless the group is back to empty. If we allow new member to provide a list of protocol type instead ("consumer", "stream"), there would be no compatibility issue.
Alternative approach is to invent an admin API to change group's protocol type on runtime. However, the burden introduced on administrator is not trivial, since we need to guarantee the operation series to be correct, otherwise we will see limp-upgrade experience in the midpoint, for example while we are changing protocol type there was unexpected rebalance that causes old members join failure.