https://emqx.atlassian.net/browse/EMQX-6978
[Related EIP](c4864eeccb/active/0022-forward-check-install-upgrade-script.md)
Currently, when performing a hot upgrade, the scripts that are run are
those from the currently installed EMQX version. It has a validation
that prevents upgrade between different minor versions. If we want to
allow an upgrade from, say, 5.0.x to 5.1.y, then the scripts in
already released packages will deny such operation. Also, if an
upgrade installation script contains a bug in the current, it will
never be able to execute properly without manual patching.
By attempting to execute the scripts from the target version, we may
add fixes and new validations to new EMQX versions and have them
executed by older versions.
Before this change, if a license in `emqx.conf` was of type
`key`/`file` and then changed to the opposite type, such change would
be saved to `{cluster,local}-overrides.conf`. When the node restarts
after that, the configs are merged naively and becomes invalid, as it
contains both the `key` and `file` keys, and crashes.
The CLI emqx_ctl fails:
```
./bin/emqx_ctl status
Node not initialized?
Generated config file vm.*.args is not found for command 'ctl'
in config dir: /Users/liuxy/code/emqx50/_build/emqx/rel/emqx/-emqx_data_dir /Users/liuxy/code/emqx50/_build/emqx/rel/emqx/data --/configs
In case the file has been deleted while the node is running,
set environment variable 'EMQX_NODE__NAME' to continue
```
The main slow-down is the overheads of booting up beam with the
'start_clean' boot file (which loads all modules).
Prior to this change, beam is started multiple times in order to
resolve configuration values.
After this change:
* For boot commands such as 'start', 'console' and
'foreground', it starts beam twice:
- 1st is to check platform compatibility
- 2nd is to resolve all configs required for boot in a batch
* For non-boot commands, such as 'ctl' and 'ping', it does not
require to start beam for config resolution at all
Adds a check to `bin/emqx` to see if the OTP version being used has
support for `mnesia_hook`, which is required by Mria for using the
RLOG backend. If OTP is not compatible and the user tries to use
RLOG, a warning is printed during startup and the configuration falls
back to using the Mnesia backend.
Thales Macedo Garitezi