New health checks for metadata store initialization

[michaelklishin]

This introduces two new health checks

• rabbitmq-diagnostics check_if_metadata_store_is_initialized
• rabbitmq-diagnostics check_if_metadata_store_is_initialized_with_data

and their HTTP API counterparts:

• GET {prefix}/health/checks/metadata-store/initialized
• GET {prefix}/health/checks/metadata-store/initialized/with-data

The first one relies on rabbit_db:is_init_completed/0, which is already used by a few
code paths, namely peer discovery, to detect when the metadata store initialization has
completed.

The second check is more opinionated: it assumes that a cluster will always have
at least one virtual host. Technically you can delete the only virtual host in the system
but then the cluster would not be practically useful.

So let's use this clue, at least one virtual host that the metadata store contains,
as a good enough indication that the metadata store has synced "just enough" for client
connections to have a chance of succeeding.

Note that these checks cannot be 100% accurate in the case of Mnesia because some data may still be in flight but should be pretty accurate in the case of Khepri, which is
the future of RabbitMQ in any case.

In any case, we currently do not provide a health check like this, which makes the problem
outlined in #13153 harder to spot and comprehend.

References #13153.