(cherry picked from commit c38a3d697d83cafa376592a9aa213347ae1a68af)
(cherry picked from commit 515780f5d4e036efb2c568214d7b1b505d5b560b)

# Conflicts:
#	deps/rabbit/src/rabbit_classic_queue_index_v2.erl
#	deps/rabbit/src/rabbit_classic_queue_store_v2.erl
#	deps/rabbit/src/rabbit_fifo.erl
#	deps/rabbit/src/rabbit_fifo.hrl
#	deps/rabbit/src/rabbit_fifo_dlx.erl
#	deps/rabbit/src/rabbit_fifo_dlx.hrl
#	deps/rabbit/src/rabbit_fifo_dlx_client.erl
#	deps/rabbit/src/rabbit_fifo_dlx_sup.erl
#	deps/rabbit/src/rabbit_fifo_dlx_worker.erl
#	deps/rabbit/src/rabbit_fifo_v1.erl
#	deps/rabbit/test/classic_queue_prop_SUITE.erl
#	deps/rabbit/test/quorum_queue_SUITE.erl
#	deps/rabbit/test/rabbit_fifo_dlx_SUITE.erl
#	deps/rabbit/test/rabbit_fifo_dlx_integration_SUITE.erl
#	deps/rabbit_common/src/rabbit_date_time.erl
#	deps/rabbitmq_shovel_management/src/rabbit_shovel_mgmt.hrl
#	deps/rabbitmq_shovel_management/src/rabbit_shovel_mgmt_util.erl
#	deps/rabbitmq_stream/test/rabbit_stream_manager_SUITE.erl

Naming from #4305 (backport #4307) (backport #4309)

Adopt latest rabbitmq-server-buildenv:linux-erlang-23.3 for RBE (backport #4308) (backport #4310)

(cherry picked from commit a43d9890d51537afde003e66f7e808e3a03fb298)
(cherry picked from commit 16b19baf0f1b90ad69add14de2cba306d6f5fc54)

for remote build execution (RBE) with BuildBuddy

(cherry picked from commit 3fa7357df93e14ccc78fc0a9f1b235fc88a487b8)
(cherry picked from commit e7ba67c8a11b25839bf47eeb2d18c7db1ee3eeb4)

Make backing_queue_SUITE fast on macOS (backport #4297) (backport #4298)

This very small patch requires extended explanations. The patch
swaps two lines in a rabbit_variable_queue setup: one which sets
the memory hint to 0 which results in reduce_memory_usage to
always flush to disk and fsync; and another which publishes a
lot of messages to the queue that will after that point be
manipulated further to get the queue in the exact right state
for the relevant tests.

The problem with calling reduce_memory_usage after every single
message has been published is not writing to disk (v2 tests do
not suffer from performance issues in that regard) but rather
that rabbit_queue_index will always flush its journal (containing
the one message), which results in opening the segment file,
appending to it, and closing it. The file handling is done
by file_handle_cache which, in this case, will always fsync
the data before closing the file. And that's this one fsync
per message that makes the relevant tests very slow.

By swapping the lines, meaning we publish all messages first
and then set the memory hint to 0, we end up with a single
reduce_memory_usage call that results in an fsync, at the
end. (There may be other fsyncs as part of normal operations.)
And still get the same result because all messages will have
been flushed to disk, only this time in far fewer operations.

This doesn't seem to have been causing problems on CI which
already runs the tests very fast but should help macOS and
possibly other development environments.

(cherry picked from commit 7198d4720ba051851e2242ad1859f32f66b3226b)
(cherry picked from commit 6773df447d7cf662d44207ea2c41f8b873478b00)

Adopt latest rabbitmq-server-buildenv:linux-erlang-24.3 for RBE (backport #4293) (backport #4294)

for remote build execution (RBE) with BuildBuddy

(cherry picked from commit 7c02878c684e8742ae006b862350c1951be38c6b)
(cherry picked from commit f2642c7b40a5e0a10eee64cd7c6af8f7dab6df7e)

Update 3.9.14 release notes

(cherry picked from commit 7eb9dd13c352821fc7835d31b40d758e1d2a5aab)