Due to:
* Cluster RPC MFA is not idempotent!
* There is a lack of rollback for callback's side-effects
For instance, when two nodes try to add a cluster-singleton
concurrently, one of them will have to wait for the table lock
then try to catch-up, then try to apply MFA.
The catch-up will have the singleton created, but the initiated
initiated multicall apply will fail causing the commit to rollback,
but not to 'undo' the singleton creation.
Later, the retries will fail indefinitely.
Depending on the order that a cluster of core nodes might be stopped
and then restarted, there might be a deadlock or crash during the
configuration loading. The nodes try to check with each other which
has the latest cluster overrides and copy that info. However, in some
cases, Mnesia on node A might still think that it needs to consult
another node C that is still down, so that this node proceeds with its
boot sequence but `mnesia:wait_for_tables` in `emqx_cluster_rpc` is
stuck. Meanwhile, a node B can come up, try to copy from the sole
online node A, and fail because it's not ready yet.
* feat(emqx_conf): move conf manager for emqx_machine to emqx_conf
* chore(emqx_conf): change emqx:get_config/2 to emqx_conf:get/2
* fix: common test failed
* fix: badmatch by typo wrong key
* fix(emqx_conf): get the wrong core nodes
* fix(emqx_conf): get core node's tnx_id not latest tnx_id
* fix: add ro_transation when copy conf file
* fix: delete debug info
* fix: change ekka_rlog to mria_rlog
* fix: remove cluster_rpc from emqx_machine.
* fix: don't call ekka:start/0 explicitly
* fix: ekka should be start in emqx_machine
Zhongwen Deng