without it, the new keys (or rather, their defaults) will spill into the `config_schema_SUITE`s of other plugins.

(cherry picked from commit 4ff6b2a)

(cherry picked from commit a7a2cac)

We implement the `revive/0` part for symmetry. As with the revive command in general, it serves as a last resort available for rollback.

Usually nodes put into maintenance mode are shortly stopped for upgrading or reconfiguration.

(cherry picked from commit 283aa0e)

(cherry picked from commit 1721af8)

Previously, the following three supervisors used the wrong `shutdown`
and wrong `type`:
* rabbit_exchange_federation_sup
* rabbit_federation_sup
* rabbit_queue_federation_sup

For `shutdown` Erlang/OTP recommends:
"If the child process is another supervisor, the shutdown time must be
set to infinity to give the subtree ample time to shut down. Setting the
shutdown time to anything other than infinity for a child of type supervisor
can cause a race condition where the child in question unlinks its own children,
but fails to terminate them before it is killed."

For `type` Erlang/OTP recommends:
"type specifies if the child process is a supervisor or a worker.
The type key is optional. If it is not specified, it defaults to
worker."

This commit fixes the wrong child spec by using a timeout of `infinity`
and type `supervisor`.

(cherry picked from commit cfcf6cf)
(cherry picked from commit e40387e)

 ## What?

Federation links started in the federation plugins are put
under the `rabbit` app supervision tree (unfortunately).

This commit ensures that the entire federation supervision hierarchies
(including all federation links) are stopped **before** stopping app
`rabbit` when stopping RabbittMQ.

 ## Why?

Previously, we've seen cases where hundreds of federation links are
stopped during the shutdown procedure in app `rabbit` leading to
federation link restarts happening in parallel to vhosts being stopped.
In one case, the shutdown of app `rabbit` even got stuck (although there
is no evidence that federation was the problem).

Either way, the cleaner appraoch is to gracefully stop all federation
links, i.e. the entire supervision hierarchy under
`rabbit_exchange_federation_sup` and `rabbit_queue_federation_sup`
when stopping the federation apps, i.e. **before** proceeding to stop
app `rabbit`.

 ## How?

The boot step cleanup steps for the federation plugins are skipped when
stopping RabbitMQ.

Hence, this commit ensures that the supervisors are stopped in the
stop/1 application callback.

This commit does something similar to #14054
but uses a simpler approach.

(cherry picked from commit 8bffa58)
(cherry picked from commit 512553e)

# Conflicts:
#	deps/rabbitmq_federation_common/src/rabbit_federation_pg.erl

when the core now interacts with a part of the
supervision tree owned by this plugin for
more efficient shutdown.

(cherry picked from commit 807e186)

(cherry picked from commit 19bb842)

(cherry picked from commit 59e9f7a)

…t_condition/2