Feature request: allow setting message properties in AMQPConnection

[RLSWE]

As seen in the README, the way to send RPC is doing something like so:

const response = await amqpConnection.request<ExpectedReturnType>({
  exchange: 'exchange1',
  routingKey: 'rpc',
  payload: {
    request: 'val',
  },
  timeout = 10000, // optional timeout for how long the request
  // should wait before failing if no response is received
});

RabbitMQ messages are capable of setting per-message properties.
Beside the basic properties, some optional properties are available, like correlation id, reply-to, etc... https://www.rabbitmq.com/publishers.html#message-properties

Currently there is no way of setting such properties using AMQPConnection.
It seems that the implementation using amqplib should be fairly easy:
https://github.com/squaremo/amqp.node/blob/main/lib/api_args.js#L223

Unfortunately I don't have the time to do so right now, maybe I'll open a PR in a week or two from now, if no one else picked it up

[WonderPanda]

I'm not sure about correlation and reply-to as both of those are specfically managed by the library in order to make RPC work properly using RabbitMQs direct-reply-to functionality but there are definitely some useful ones that people might want to leverage that should be exposed

[RLSWE]

Yea I think mainly for us what's missing is the expiration.
expiration sets TTL (time to live) per message. The problem we are seeing not having that can be seen in that example:

• Microservice A sends an RPC that eventually should create some entity via Microservice B and get that entity from B
• Microservice B is currently down for some reason
• Microservice A get's a timeout -> Eventually showing the user that an error occured
• Microservice B comes back to life
• No TTL is set, so RabbitMQ sends it to the first candidate that can digest it (B)
• Microservice B executes something it shouldn't

Setting expiration along with the timeout could save a lot of trouble for us :P

[underfisk]

@RoniLeshes I'll implement this options but a warning about some other properties such as the correlationId because they can interfere with, a warning would be dispatched in the console if the correlationId is overwritten

[WonderPanda]

@RoniLeshes I'll implement this options but a warning about some other properties such as the correlationId because they can interfere with, a warning would be dispatched in the console if the correlationId is overwritten

I think we should just start with expiration and not allow them to override correlationId until we have a clearer understanding of the use case