br supports fast fail when restoring with incompatible settings

[IANTHEREAL]

Feature Request

Describe your feature request related problem:

one example: if the collation configuration of backup & restore tidb cluster is different, br restore will fail as expected. However, the user only sees the checksum failure through the log, and does not know that it is caused by the inconsistency of the collation configuration.

Describe the feature you'd like:

br should support fast fail In all similar scenarios

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

[kennytm]

For collation:

1. On backup, add a field to record the "new collation"-ness into backupmeta (true / false / null)

2. On restore, compare the backupmeta's "new collation"-ness vs the cluster's "new collation"-ness:

   backupmeta \ Target	New	Old
   New (true)	✔️ Allow	❌ Deny
   Old (false)	❌ Deny	✔️ Allow
   Unknown (null)	⚠️ Allow with warning	⚠️ Allow with warning

3. The check can be disabled through --check-requirements=false.

4. The check must not apply with br restore raw.

Is there any other cluster-wide incompatible settings?

[IANTHEREAL]

@bb7133 Is there any other cluster-wide incompatible settings?