Replace queue factory with queue providers

[vjik]

Q	A
Is bugfix?	❌
New feature?	❌
Breaks BC?	✔️

[viktorprogger]

It's not enough just to set a channel name into a queue object. In the old factory we used a default (base) adapter too:

return $this->queue->withChannelName($channel)->withAdapter($this->defaultAdapter->withChannel($channel));

[vjik]

I plan fix it another PR. withChannelName in Queue should be enough and Queue should configure own adapter himself.

[viktorprogger]

Anyway this PR should work as expected before merging it into master.

[vjik]

Fixed in Queue::withChannelName.

[viktorprogger]

In my opinion this functionality shouldn't be accessible by default, as it's too easy to make a mistake and run out of resources on a production server by spamming with new open connections. In the QueueFactory this functionality was protected by the enableRuntimeChannelDefinition configuration flag.

[vjik]

We decided to remove Queue::withChannelName metod in future PR.

[viktorprogger]

Let's add definitions for all the providers, so if users want to use one of them, they can do it easily with just setting a definition for the provider interface.

AdapterFactoryQueueProvider::class => [...],
QueueFactoryQueueProvider::class => [...],

// and set the default one
QueueProviderInterface::class => AdapterFactoryQueueProvider::class,

[vjik]

Now the configuration is as it was before. I want to improve package configuration in one of the next PRs.

[viktorprogger]

There is no guarantee those future PRs will be merged into master soon. Those who already use this package should have a convenient configuration now. Let's do it before the PR is merged.

[vjik]

Currently package in dev status. It's OK.

[viktorprogger]

For a not released package I'm for making a breaking change, but I'm against lack of configuration. I have two arguments for this:

• Some people already use this package. I'd prefer to make its usage as comfortable as we can. Despite there are breaking changes.
• If a change needs to have a default configuration, it should have a default configuration from the very beginning. This way we'll avoid decisions, which are good at architectural point, but are hard to be used in real-life projects. The goal is to provide some default configuration, document it and see if it's really comfortable to use in a project. If it's impossible to describe it in simple words - than the decision is likely to be reimagined and simplified for the end user.