Regression with Khepri and binding arguments

[ansd]

Describe the bug

Khepri handles routing decision incorrectly when multiple bindings are created to a source exchange of exchange type direct or fanout when different binding arguments are used.

Note that such binding arguments are entirely ignored when RabbitMQ performs routing decisions for the direct or fanout exchange. However, there might be client apps that use binding arguments to add some metadata to the binding, for example app-id or user or purpose and might use this metadata as a form of reference counting in deciding when to delete auto-delete exchanges or just for informational/operational purposes. So, this bug only occurs for edge cases.

Reproduction steps

On branch https://github.com/rabbitmq/rabbitmq-server/tree/binding-args-khepri-bug run

make -C deps/rabbit ct-bindings t=cluster:binding_args RABBITMQ_METADATA_STORE=mnesia

and

make -C deps/rabbit ct-bindings t=cluster:binding_args RABBITMQ_METADATA_STORE=khepri

The test succeeds with Mnesia and fails with Khepri.

Expected behavior

Khepri routes correctly.

Additional context

The problem is that ETS table rabbit_khepri_index_route cannot
differentiate between two bindings with different binding arguments, and
therefore deletes entries too early, leading to wrong routing decisions.

The solution to this bug is to include the binding arguments in the
rabbit_khepri_index_route projection, similar to how the binding args
are also included in the rabbit_index_route Mnesia table