[RIP-44] Support DLedger Controller

[RongtongJin]

What is the purpose of the change

After the release of RocketMQ 4.5.0, the DLedger mode (raft) was introduced. The raft commitlog under this architecture is used to replace the original commitlog so that it has the ability to failover. However, there are some disadvantages going with this architecture due to the raft capability on replication, including:

1. To have failover ability, the number of replicas in the broker group must be 3 or more

2. Acks from replicas need to strictly follow the majority rule of the Raft protocol, that is, 3-replica architecture requires acks from 2 replicas to return, and 5-replica architecture requires acks from 3 to return

3. Since the store repository relies on OpenMessaging DLedger in DLedger mode, Native storage and replication capabilities of RocketMQ (such as transientStorePool and zero-copy capabilities) cannot be reused, and maintenance becomes difficult as well.

To handle those mentioned problems, I would like to start an RIP-44 Support DLedger Controller. With this improvement, DLedger (Raft) capability will be abstracted onto the upper layer, becoming an optional and loosely coupled coordination component named DLedger Controller.

After the deployment of DLedger Controller, the master-slave architecture will also equip with failover capability. The DLedger Controller can optionally be embedded into the NameServer (the NameServer itself remains stateless and cannot provide electoral capabilities when the majority is down), or it can be deployed independently.

DLedger controller is an optional component that does not change the previous operation and maintenance mode. Compared with other components, its downtime will not affect online services. In addition, RIP-44 unifies the storage and replication of RocketMQ, resulting in lower maintenance costs and faster development iterations. In terms of compatibility, the master-slave architecture can upgrade without compatibility problems.

I've already done part of the work with @hzh0425 . Our proposals are provided at the links below：

https://docs.google.com/document/d/1tSJkor_3Js4NBaVA0UENGyM8Mh0SrRMXszRyI91hjJ8/edit?usp=sharing

Chinese version：

https://shimo.im/docs/N2A1Mz9QZltQZoAD/

Brief changelog

Refer https://shimo.im/docs/N2A1Mz9QZltQZoAD#anchor-qJhl

Verifying this change

Refer UTs, ITs and testing report

Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

• Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
• Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test to make sure integration-test pass.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

[RongtongJin]

6.29 review意见:

1. 以SyncStateSet不以IP作为依据，而是以brokerId（Controller给broker的唯一编号）作为依据，HA部分同步要改。
2. 整理InSyncReplicas、minInSyncReplicas在Controller模式下含义，当SyncStateSet个数小于minInSyncReplicas时，副本写入将不再成功，返回PutMessageStatus.IN_SYNC_REPLICAS_NOT_ENOUGH
3. 不再复用NameServer的心跳，都使用Controller独立的心跳、去掉controllerDeployedStandAlone参数，心跳包新增maxOffset、confirmOffset、last epoch等字段。这些会作为选举的依据
4. 选举后SyncStateSet应该继承下来而不是直接变为新Master，一个场景是新被选出的主，该主马上又挂了，此时就没有master可以被选举（不过从当前实现来看，若改为继承，slave若没有马上连到master，会增加故障恢复的时间，并且master会马上更新新的SyncStateSet，而slave连上master首先需要获取haMasterAddress从namesrv注册结果中返回，需要一段时间（考虑在controller中维护haMasterAddress）），同时这种情况下注意confirmOffset回退问题（先进行分析）
5. Controller 的格式带上rocketmq message header，以便于后面扩展
6. 对于磁盘坏、心跳好的情况，需要再细分PutMessageStatus（能显示磁盘坏），如果磁盘坏了，同样需要选举切换。

已完成第2、3点修复。第1点修复@hzh0425进行中

[ShannonDing]

LGTM

[lizhiboo]

LGTM

[hzh0425]

Thanks~