feat(rabbitmq): Add support for simulating RPC servers.

[docknight]

Description

Complementing the previously introduced client execution type, a new server type has been introduced to simulate server side of the RPC pattern using Direct Reply-to.

It can be used to test a client that is expected to send a request and is awaiting a reply to be received on the queue determined by the ReplyTo property of the request message.

Usage

Example testsuite:

name: TestSuite RabbitMQ
testcases:
  - name: Receive request and send a reply
    steps:
      - type: rabbitmq
        addrs: "{{.addrs}}"
        user: "{{.user}}"
        password: "{{.password}}"
        qName: "{{.qName}}"
        clientType: server
        exchange: test-exchange
        exchangeType: direct
        durable: true
        routingKey: OrderDetailsRequest
        messages: 
          - value: '{"Status": "OK", "OrderDate": "2024/11/07", "OrderStatus": "Pending"}'
            contentType: application/json
            contentEncoding: utf8
            persistant: false
            durable: true
        assertions: 
          - result.bodyjson.bodyjson0 ShouldContainKey OrderId

In the above example, the test executor will wait for a request message to be received on the queue. It will then publish a reply to the reply queue specified in the ReplyTo header of the request message (this might be the auto-generated reply queue if the Direct Reply-To feature of rabbitmq is used by the RPC client).

Additional changes

Previously, the consumer implementation was relying on a message to already be present in the consuming queue, breaking the test execution if the executor was started before the publishing SUT (System Under Test). This has now been changed: the test executor will wait until messages arrive into the queue, and then start processing them. This is applicable to subscriber and server execution types.