[SecurityBundle] correct types for default arguments for firewall configs

[shieldo]

Q	A
Branch?	3.4 (and forward)
Bug fix?	yes
New feature?	no
Deprecations?	no
Tickets	n/a
License	MIT
Doc PR	n/a

Up until now, the default template arguments in the security.firewall.config abstract service definition have been each defined (aside from the argument for $listeners which is given a collection type) in the XML as

<argument />

which resolves to an empty string, despite that some of the arguments are typed to being either bool or array|null on the Symfony\Bundle\SecurityBundle\Security\FirewallConfig class itself.

This wouldn't be so much of a problem if the child definitions that use this as a template overrode all the arguments every time, but in the case of firewall configs that mark security as not being enabled, only the first few arguments are overwritten, so firewall config objects that do not have security enabled are instantiated by the DI container with parameters with some of the wrong types.

In general this wouldn't be an issue, as firewalls with security not enabled would not usually be consumed in a context where further security-related config were needed, but there is a case in Symfony\Bundle\SecurityBundle\DataCollector\SecurityDataCollector where the method getSwitchUser() on the firewall config object can be called without checking first whether the firewall has security enabled, which leads to an exception being thrown:

Symfony\Component\Debug\Exception\ContextErrorException
Warning: Illegal string offset 'parameter'
in vendor/symfony/symfony/src/Symfony/Bundle/SecurityBundle/DataCollector/SecurityDataCollector.php (line 184) 

which is down to the firewall config being set with an empty string rather than null (in which case the logic here would function as expected).

It seemed most appropriate as a fix (especially given possible introduction of scalar type hints in the future) to apply types to the default arguments so that it was no longer possible to instantiate a firewall config object with parameters of unexpected types.

[chalasr]

Good catch, thanks @shieldo.