feat: init concurrent rpc for rabbit broker

[sfran96]

Description

Refactoring of the _RPCCallback class to RPCManager with support for an RPC consumer per channel. Took some inspiration from what was discussed in #1318 and made adaptations to what's explained in the RabbitMQ direct reply-to documentation.

Closes #1318

Type of change

Please delete options that are not relevant.

• Documentation (typos, code examples, or any documentation updates)
• Bug fix (a non-breaking change that resolves an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a fix or feature that would disrupt existing functionality)
• This change requires a documentation update

Checklist

• My code adheres to the style guidelines of this project (scripts/lint.sh shows no errors)
• I have conducted a self-review of my own code
• I have made the necessary changes to the documentation
• My changes do not generate any new warnings
• I have added tests to validate the effectiveness of my fix or the functionality of my new feature
• Both new and existing unit tests pass successfully on my local environment by running scripts/test-cov.sh
• I have ensured that static analysis tests are passing by running scripts/static-analysis.sh
• I have included code examples to illustrate the modifications

[Lancetnik]

Sorry, but I don't like correlation_id mapping in the services. It is a bad way for huge RMQ cluster (too many messages we should filter). I see this feature implementation via Channel Pool usage and acquiring a new channel from the pool for each request.

[sfran96]

I understand your point, I've updated it to use the CM you added in your branch, but what I encounter is then issues when using RPC and the consumer and the publisher are in the same machine as the channel pool is shared among the two and the publisher hoards them all before the consumers can get a chance at acquiring one.

I don't know what the best solution would be here, I've read that you usually have a channel for producing and another for consuming, but then does this mean having two channel pools?

I've also tried not using the scope within the RPC callback (therefore releasing the channel back to the pool ASAP) plus a lock per channel, but then what occurs is that the channels do not scale very well with the number of concurrent RPC requests, unless the number of requests is ridiculously higher than the channel pool, so concurrency is higher but not highest.