... instead of 5 seconds. Hopefully, this should reduce the chance of
failures in CI.

Tracking is already taken care of when each channel is closed.

Removing this concurrent call to `unregister_tracked()` fixes a
double-decrease of the counter. The reason is the counter is updated
outside of a transaction and is therefore sensitive to concurrent
read/modify/write sequences.

A transaction would be a more appropriate solution, but it may be too
resources-intensive in the scenario of high connection/channel churn.

... instead of checking it just after the channel/connection was closed.

The problem with closing those resources is that the metric may be
updated after the close function returns. There the check is
time-sensitive. Waiting for the expected counter value fixes the
problem.

Several new functions for rabbit_alarms

This handles the case where the channel receives a message from a queue
that has recently been deleted. This crash would only occur when running
in a mixed versions cluster.

To wait for both new and old confirm message formats.

out of rabbit_common as it is only used by modules in the server.