[Why]
For a long time, there has been race condition when deleting
exclusive queues - if a connection was re-established and a queue
with the same name was declared, we could delete the new queue.

For example, with many MQTT consumers, if we performed a rolling restart
of the cluster and the clients reconnected without any delay, after the
restart, we sometimes had the expected number of connections but a lower
number of queues, even though there should be a queue for each consumer.

[How]
Check that the exclusive_owner has the value we expect when requesting
deletion. If the value is different, this means this is effectively a
different queue (same name, but a different connection), so we should
not delete it.

(cherry picked from commit 31ba23a)
(cherry picked from commit 8588cee)

# Conflicts:
#	deps/rabbit/src/rabbit_db_queue.erl

v4.1.x uses Khepri 0.16.0 where khepri_tx_adv:delete returns the old
single_result format ({ok, #{data := _}}), not the new many_results
format ({ok, #{Path := #{data := _}}}) introduced in Khepri 0.17.0.

The original main/v4.2.x version uses khepri_tx:does_api_comply_with/1
to handle both formats, but this function does not exist in Khepri
0.16.0.

Additionally, khepri_path:combine_with_conditions/2 is not in the
Horus allowed function list for transaction functions in Khepri 0.16.0.
Move the path computation outside the transaction function to avoid
the Horus extraction error.

Simplify the pattern matching to use only the Khepri 0.16.0 format
while preserving the fix: conditional deletion using
khepri_path:combine_with_conditions to check exclusive_owner before
deleting.