Use stream queues instead of fanouts

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/890824
Committed: https://opendev.org/openstack/oslo.messaging/commit/3438726dd08eef03a0962c72096f268a54fd7f4e
Submitter: "Zuul (22348)"
Branch: master

commit 3438726dd08eef03a0962c72096f268a54fd7f4e
Author: Arnaud Morin <email address hidden>
Date: Wed Jul 26 10:34:19 2023 +0200

    Add some logs when sending RPC messages

    Related-bug: #2031497

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: I7d0c318624d3d02182392ca3f06eed04d4133728

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/889701
Committed: https://opendev.org/openstack/oslo.messaging/commit/f23f3276c4f8c156c7a917ffd05db6b3b010b807
Submitter: "Zuul (22348)"
Branch: master

commit f23f3276c4f8c156c7a917ffd05db6b3b010b807
Author: Arnaud Morin <email address hidden>
Date: Wed Jul 26 12:12:16 2023 +0200

    Allow creating transient queues with no expire

    When an operator rely on rabbitmq policies, there is no point to set the
    queue TTL in config.
    Moreover, using policies is much more simpler as you dont need to
    delete/recreate the queues to apply the new parameter (see [1]).
    So, adding the possibility to set the transient queue TTL to 0 will
    allow the creation of the queue without the x-expire parameter and only
    the policy will apply.

    [1] https://www.rabbitmq.com/parameters.html#policies

    Related-bug: #2031497

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: I34bad0f6d8ace475c48839adc68a023dd0c380de

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/889313
Committed: https://opendev.org/openstack/oslo.messaging/commit/8e3c523fd74257a78ceb384063f81db2e92a2ebd
Submitter: "Zuul (22348)"
Branch: master

commit 8e3c523fd74257a78ceb384063f81db2e92a2ebd
Author: Arnaud Morin <email address hidden>
Date: Fri Jul 21 16:51:51 2023 +0200

    Auto-delete the failed quorum rabbit queues

    When rabbit is failing for a specific quorum queue, the only thing to
    do is to delete the queue (as per rabbit doc, see [1]).

    So, to avoid the RPC service to be broken until an operator eventually
    do a manual fix on it, catch any INTERNAL ERROR (code 541) and trigger
    the deletion of the failed queues under those conditions.
    So on next queue declare (triggered from various retries), the queue
    will be created again and the service will recover by itself.

    Closes-Bug: #2028384
    Related-bug: #2031497

    [1] https://www.rabbitmq.com/quorum-queues.html#availability

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: Ib8dba833542973091a4e0bf23bb593aca89c5905

Related fix proposed to branch: stable/2023.2
Review: https://review.opendev.org/c/openstack/oslo.messaging/+/900891

Reviewed: https://review.opendev.org/c/openstack/oslo.messaging/+/900891
Committed: https://opendev.org/openstack/oslo.messaging/commit/34260a40358b17980f151dd6f4c4145533fba799
Submitter: "Zuul (22348)"
Branch: stable/2023.2

commit 34260a40358b17980f151dd6f4c4145533fba799
Author: Arnaud Morin <email address hidden>
Date: Fri Jul 21 16:51:51 2023 +0200

    Auto-delete the failed quorum rabbit queues

    When rabbit is failing for a specific quorum queue, the only thing to
    do is to delete the queue (as per rabbit doc, see [1]).

    So, to avoid the RPC service to be broken until an operator eventually
    do a manual fix on it, catch any INTERNAL ERROR (code 541) and trigger
    the deletion of the failed queues under those conditions.
    So on next queue declare (triggered from various retries), the queue
    will be created again and the service will recover by itself.

    Closes-Bug: #2028384
    Related-bug: #2031497

    [1] https://www.rabbitmq.com/quorum-queues.html#availability

    Signed-off-by: Arnaud Morin <email address hidden>
    Change-Id: Ib8dba833542973091a4e0bf23bb593aca89c5905
    (cherry picked from commit 8e3c523fd74257a78ceb384063f81db2e92a2ebd)