feat(schema validation): implement backup restore

[thalesmg]

Fixes https://emqx.atlassian.net/browse/EMQX-12346

Release version: e5.7

Summary

From discussions with Product, when importing a schema validation backup:

• Existing validations (identified by `name') are left untouched.
• No validations are removed.
• New validations are appended to the existing list.
• Existing validations are not reordered.

PR Checklist

Please convert it to a draft if any of the following conditions are not met. Reviewers may skip over until all the items are checked:

• Added tests for the changes
• Added property-based tests for code which performs user input validation
• Changed lines covered in coverage report
• Change log has been added to changes/(ce|ee)/(feat|perf|fix|breaking)-<PR-id>.en.md files
• For internal contributor: there is a jira ticket to track this change
• Created PR to emqx-docs if documentation update is required, or link to a follow-up jira ticket
• Schema changes are backward compatible

Checklist for CI (.github/workflows) changes

• If changed package build workflow, pass this action (manual trigger)
• Change log has been added to changes/ dir for user-facing artifacts update

[zmstone]

i wonder if there are some inconsistent behaviour for config import comparing to config load API (which has a mode option supporting replace or merge)

[zmstone]

this generates small config changes,
would it make sense to merge all configs and reload all at once?

[thalesmg]

✔️

[zmstone]

i wonder if there are some inconsistent behaviour for config import comparing to config load API (which has a mode option supporting replace or merge)

There is maybe a missing support for config load API (and CLI) ?

[zhongwencool]

The Old map of prepare_config_merge/2 has atom as key in pre_config_update, but in post_config_update it is binary. This was not considered in the implementation.
By the way, why is there a need to do merge again in post after it has been done in pre_config_update?
It seems to be some kind of conflict. Maybe, we could handle nothing in pre_config_update and deal with it directly in post_config_update.

[thalesmg]

The Old map of prepare_config_merge/2 has atom as key in pre_config_update, but in post_config_update it is binary. This was not considered in the implementation.

Good catch.

By the way, why is there a need to do merge again in post after it has been done in pre_config_update?
It seems to be some kind of conflict. Maybe, we could handle nothing in pre_config_update and deal with it directly in post_config_update.

Indeed, there's no work needed in pre_config_update. Thanks! 🍻

Actually, we do need to repeat the work: when "merging", we only add new validations.

[zhongwencool]

LGTM, I merge this first, Let QA team help to verify this.

[emqxqa]

TestExecution