✨ feat: enable separate producer and consumer kafka clusters

[wss-rbrennan]

This PR enables Featbit to function with Highly Available, Cross Data Center/Cross Region Kafka Clusters by allowing consumers to consume from different clusters than producers.

The scenario in which this is useful is a deployment that will use a Primary Cluster and a Secondary Aggregate Cluster, with Mirror Maker 2 synchronizing data from the local Primary to the local Secondary. All Producers will write to the local Primary and all Consumers will read from the local Aggregate. Additionally, Mirror Maker would perform one way synchronization between the local Primary Cluster and the Remote Aggregate Cluster. This keeps the Kafka Aggregate (or "consumer") clusters synchronized across data centers in near real-time, and keeps Clickhouse synchronized between data centers without the need for additional cross data center replication.

Testing Backward Compatibility:

1. Either start with a completely fresh installation using docker-compose-pro-dev.yml or bring up the docker compose file with the --build flag so the containers are using the new code.
2. Once the application is started go to the Kafka UI http://127.0.0.1:8080/ and observe there is one cluster, and navigate to the consumers view (found in the left navigation) on the consumers view observe that there are three consumers api, ch_group, and evaluation-server.
3. If needed, In the Featbit UI create a flag or flags.
4. perform other tests such as changing flag states in the Featbit UI, or running an application that uses an sdk that includes user information
5. observe that relevant topic message counts increase in the Kafka UI after those actions are taken.

Testing New Functionality:

1. start with a completely fresh installation using docker-compose-pro-dev-HA-kafka.yml
2. Once the application is started go to the Kafka UI http://127.0.0.1:8080/ and observe there are two clusters
3. navigate to the consumers view (found in the left navigation) for the featbit-kafka cluster
4. on the consumers view observe that there are no consumers
5. navigate to the consumers view (found in the left navigation) for the featbit-kafka-consumer cluster
6. on the consumers view observe that there are three consumers api, ch_group, and evaluation-server
7. In the Featbit UI create a flag or flags.
8. perform tests such as changing flag states in the Featbit UI, or running an application that uses an sdk that includes user information
9. observe that related topic message counts increase in the Kafka UI after those actions are taken for both the featbit-kafka cluster, and the featbit-kafka-consumer cluster.

Note: It may be necessary to close your browser entirely and reopen it between testing docker-compose-pro-dev.yml and docker-compose-pro-dev-HA-kafka.yml otherwise the UI may fail to render. The cause was not investigated, but the assumption is that the browser is holding an invalid authentication cookie from the previous deployment.

[deleteLater]

Wow, that's amazing. Thanks for your contribution ❤️

[deleteLater]

the UI may fail to render. The cause was not investigated, but the assumption is that the browser is holding an invalid authentication cookie from the previous deployment.

Yeah, we usually clear the local storage in this case. The reason is that we store organization and project information in the local storage, which is then used to load the UI. In this situation, the information becomes outdated (from the previous run), so the UI fails to render.

[deleteLater]

LGTM