Avoid registering the strategy listener when it is useless

[stof]

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
Related tickets	n/a
Documentation	n/a
License	MIT

If both the client and the async client are null, the strategy would never find any candidates. In such case, it is useless to register it as a kernel.request listener to prepend itself to the discovery, as it would not have any effect on the discovery, but it requires work on each request.

[fbourigault]

The service is public. I hope anybody rely on it, but in such case is it considered as a BC break? IMHO, it requires at least a note in the CHANGELOG.

[stof]

Well, it is public because event listeners are required to be public (in Symfony < 3.3). But getting this service in your own code is totally useless as it is about 2 things:

• being a discovery strategy (which is an internal part of the discovery itself, and so people should not call it directly), and even a useless strategy in the case where it is removed (why would you call an internal service of another bundle when you wrote explicit configuration to make it always return an empty array). Thus, the strategy part is a static API so people might not even be calling the service.
• being an event listener to register the strategy (which is the part doing useless work).

Thus, this service is never documented anywhere.
And being in the case of removal requires explicit configuration. By default, the client discovery is in auto mode (which implies instantiating a client on each kernel.request event to configure the strategy, even when discovery is never used later. Plus it could be too late for the discovery call if they are used for a service needed earlier than this call, which makes the whole feature questionable btw). The removal only happens with this config:

httplug:
    discovery:
        client: null

I will let maintainers decide whether this deserves a changelog note or no (the changelog note might be more confusing than anything else for most people.)

[dbu]

i think this makes sense, and agree we don't need a changelog entry. the one person that might has been using it will realize it or come and ask.