Feature Request: Multi exchange and multi queue binding

[alaricode]

Feature Request: Multi exchange and multi queue binding

[AlariCode]

Thanks for support!
First we need to determine approach to this feature.

1. The one that you described. Pros: backward compatibility, easy to code. Cons: NestJS module philosophy is not supported.
2. We create forFeature() method, that declares name, queue, exchange and other parameters. And forRoot() only declare service names, logger and other common features. @RMQRoute gets additional parameter of module name, to bind correctly to the selected module. Pros: logic separation with modules, you can use different connections with different modules. Cons: no backward compatibility (I assume), more hard to implement.
   Second approach related to #20

What do you think, would be better and why?

[falahati]

I think adding the forFeature() is a must with or without this change. forFeature() allows dependency separation which might be quite useful in a modular sort of way, and as you said it, more in line with what NestJS philosophy dictates or is the norm.

However, this FR is not actually a replacement for the nonglobal modules, but rather helps decrease such needs indirectly by adding a new feature that could in the majority of cases used as a workaround. So from the modular point of view, no this feature is not ideal. However, the added functionalities are not going to be provided with the addition of forFeature anyway, so one can argue that this feature is completely separate.

But yeah, I suppose forFeature is more preferable. If we write it the way TypeORM does it we might be able to allow backward compatibility. But I have to double-check. I will take a look into this and keep you in the loop for any finding; might even submit a PR for forFeature. But in any case, if backward compatibility is broken, you can release a new major version, the migration for users would be easy.