For 4.1.4: Fix channel number reuse (backport #14317)

[mergify]

This commit fixes the following test flake that occurred in CI:

make -C deps/rabbit ct-amqp_dotnet t=cluster_size_1:redelivery

After receiving the end frame, the server session proc replies with the end frame.

Usually when the test case succeeds, the server connection process receives a DOWN for the session proc and untracks its channel number such that a subsequent begin frame for the same channel number will create a new session proc in the server.

In the flake however, the client receives the end, and pipelines new begin, attach, and flow frames. These frames are received in the server connection's mailbox before the monitor for the old session proc fires. That's why these new frames are sent to the old session proc causing the test case to fail.

This reveals a bug in the server.
This commit fixes this bug similarly as done in the AMQP 0.9.1 channel in

rabbitmq-server/deps/rabbit/src/rabbit_channel.erl

Lines 1146 to 1155 in 94b4a6a

	%% We issue the channel.close_ok response after a handshake with
	%% the reader, the other half of which is ready_for_close. That
	%% way the reader forgets about the channel before we send the
	%% response (and this channel process terminates). If we didn't do
	%% that, a channel.open for the same channel number, which a
	%% client is entitled to send as soon as it has received the
	%% close_ok, might be received by the reader before it has seen
	%% the termination and hence be sent to the old, now dead/dying
	%% channel process, instead of a new process, and thus lost.
	ReaderPid ! {channel_closing, self()},

Channel reuse by the client is valid and actually common, e.g. if channel-max is 0.

---

This is an automatic backport of pull request #14317 done by Mergify.