[HttpFoundation] Add ParameterBag::getString() and deprecate accepting invalid values

[GromNaN]

Q	A
Branch?	6.3
Bug fix?	no
New feature?	yes
Deprecations?	yes
Tickets	Fix #44787 #48219
License	MIT
Doc PR	symfony/symfony-docs#...

There were a lot of discussions on #44787 regarding the implementation. The main debate is to determine the right behavior when the value is invalid: try to convert the value, throw an exception, return the default value or the falsy?

I added plenty of test cases for the methods getAlpha, getAlnum, getDigits, getInt, getInteger, getString so that we can discuss the expected result for each input value.

My goals:

• Provide safe methods to get values in the expected type. Example: The parameters being generally of type string, the getString method is useful to be sure we don't get an array.
• Reduce deprecations on methods that exist since Symfony 2.0, in one of the most popular Symfony component.

How are these getter methods used?

• Most of the time, parameter values are string (from routing, query string, request payload). get is used but does not validate the return type.
• getInt is used for pagination (UX Autocomplete) or getting an index (EasyAdmin)
• I think there was an unidentified breaking change when we introduced return types #42507. Methods getAlpha, getAlnum and getDigits could return an array, but their return type have been modified to string, resulting in a TypeError. example of use

[GromNaN]

I don't really like the extra argument to handle the BC layer because it means we're going to have to deprecate it in 7.1 + remove it in 8.0. Looks like a costly change. But I don't have a better idea other than just changing the behavior on 6.3 without this layer...

I'll take care of this process 😃.

But I am also tempted to change the behavior directly in 6.3. The modification to keep the current behavior is to replace $parameters->getInt('page') by (int) $parameters->get('page'). This change in user code is compatible with all previous version of Symfony and could be applied as a bugfix in all existing codebase that want to fallback to 0 in case of invalid value.

[GromNaN]

or better: we (plan to) throw unless FILTER_NULL_ON_FAILURE is explicitly set, and we drop the error_on_failure option

This is a brilliant idea, let me explain it for the readers.
Historically, filter_var returns false in case of invalid data. But this is a design problem because you can't tell a false from FILTER_VALIDATE_BOOLEAN from a false from an invalid value. So FILTER_NULL_ON_FAILURE was introduced in PHP 5.2 to allow differentiating errors. So we should always use this flag.
We will use the absence of this flag to define our default behavior in Symfony 7.0: throw an exception in case of invalid data.

[nicolas-grekas]

(I improved the deprecation message)

[fabpot]

Thank you @GromNaN.