Allow disabling an exporter via an API

[deepthidevaki]

For dual-region, we have an ElasticSearch exporter for each region separately. During failover, we want to disable the exporter to the failed region to ensure that Zeebe can continue exporting to the surviving exporter and compact the logs.

As discussed in the poc, we will built this feature on top of the cluster topology which allows to keep track of the latest state of the exporter and make changes in a systematic and observable manner.

The state of exporter is persisted in the cluster

Beta Give feedback

1. Rename topology module and classes to be more generic zeebe#18032
   +0
   
2. Add exporter state to topology zeebe#18033
   kind/task scope/broker +2
   
3. Initialize exporter state in dynamic config during bootstrap zeebe#18034
   version:8.6.0-alpha2 +1
   

I can disable an exporter by its id with out restarting the cluster

Beta Give feedback

1. Allow ExporterDirector to disable an exporter zeebe#18356
   component/zeebe kind/task scope/broker version:8.6.0-alpha2 +4
   
2. Allow PartitionManager to disable an exporter in a partition #18419
   component/zeebe kind/task scope/broker version:8.6.0-alpha2 +4
   
3. Add operation and applier for disabling exporter zeebe#18418
   component/zeebe kind/task scope/broker version:8.6.0-alpha2 +4
   
4. Coordinator can handle exporter disable request zeebe#18420
   component/zeebe kind/task scope/broker version:8.6.0-alpha2 +4
   
5. Add gateway endpoints for exporter disable request #18421
   component/zeebe kind/task scope/broker +3
   

[deepthidevaki]

Follow up discussion of #18512 (review) with @npepinpe

We decided to go with the following semantics. The feasibility of a technical solution needs to be evaluated.

1. The exporter state in the dynamic config is enabled. But the broker restarts with exporter removed from the static configuration.

In this case, the removed exporter will be automatically set to disabled by Zeebe. The state of the exporter will be removed from the runtime (which is also the current behavior.) When the exporter is re-added, it has to be explicitly enabled via the API.

Deleting the exporter completely from the dynamic config should be evaluated later. Currently due to the need for keeping metadataVersion for correctness for next re-enabling, it is required to keep the exporter in the dynamic config.

2. The exporter doesn't exist in the dynamic config. But a broker restarts with a new exporter added to the static configuration.

The newly added exporter will be enabled by default.

Technical solution idea: On restart, brokers compare the dynamic config and the static config and updates its own state in the dynamic config accordingly. Each brokers updates its own state and gossips this change. The merge logic ensures that all brokers eventually has the same dynamic configuration state. We have to ensure that this wouldn't conflict with any concurrent scaling or config change operations that updates the dynamic config.