[Symfony 6] Use Symfony\Component\HttpFoundation\InputBag where appropriate instead of ParameterBag

Nearly the same we faced in https://www.drupal.org/node/2743809

The semantics of Request::get() have changed in Symfony 3. Request attributes are now examined first before request query parameters. The use of $request->get() is highly discouraged, use $request->query->get() instead if you need to access request query parameters.

On first look
- \Drupal\media_library\MediaLibraryState extends it but now mismatch with InputBag
- \Drupal\Core\Form\FormBuilder::doBuildForm() also affected as creating request
- \Drupal\Core\Security\RequestSanitizer::sanitize() processing exactly affected bags so needs shim
- other usage in tests but around ~40 places

Primary usage looks is for _raw_variables ~20

Here's 2 approaches to replace it - patches are examples for one of tests

- aliasing to core namespace as _raw_variables is core's concept (could use separate issue to dig)
- replace the class directly (patch 2) - more changes but easy to catch remains

+1 for replacing the class directly (patch 2).

I asked @catch on slack about with which solution we should go and his answer was also option 2. It looks to me that we have consensus about the which solution to choose. Putting this issue back to needs work for implementation solution #2.

Please check if all places were properly replaced.

Hey @paulocs, I think you forgot to update one place, you updated the tests but not on the implementation, this new patch can fix the testing error.

Forgot to chante the status.

I'm so sorry for my previous interdiff, here's the correct one.

Moving to needs review due to my mistake with interdiff.

I found an inconsistency in the documentation on file core/lib/Drupal/Core/Routing/RouteMatch.php
lines 41:

  /**
   * A key|value store of raw parameters.
   *
   * @var \Symfony\Component\HttpFoundation\ParameterBag
   */
  protected $rawParameters;

and line 64:
$this->rawParameters = new InputBag($raw_parameters);

Can someone confirm if this is how was supposed to be?

Besides that, there was no addition of coding standards and the code looks to be working fine.
As soon this is resolved I can move to RTBC

@lucienchalom good catch! I've updated the code, here's a new patch.

Thank you @murilohp!
Everything looks good to me.
RTBC

I'm also not sure how much we're gaining here compared to waiting for Symfony 5.4 - we're not actually removing any deprecation messages with this, and we'll want to switch away from \Drupal\Core\Http\InputBag including where it's currently used in core one we're on 5.4 too.

Leaving RTBC but will try to get a third opinion.

Discussed briefly with @alexpott.

If we were able to make the Drupal InputBag a real forward compatibility layer, this might have been fine, but instead it was purely an internal layer so we could update calling code (which isn't necessary for the examples here). Given that, going to mark this postponed on #3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support). Once that's in, updating this patch should just be switching the use statements.

Updating the status helps.

#3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support) has landed.

Hey, I rerolled the patch, and also removed the \Drupal\Core\Http\InputBag class, since SF 5.4 landed, I don't think this is necessary anymore. If you think this is not part of the scope of this issue, I can revert and we create a new issue just for the InputBag clean up.

also removed the \Drupal\Core\Http\InputBag class, since SF 5.4 landed, I don't think this is necessary anymore.

We marked that internal for removal in 10.0.0, so it's fine to remove here!

The testbot is failing for D10.

Just did composer update.

My bad @longwave, I was having some problems testing locally then I changed the /core/tests/Drupal/TestTools/PhpUnitCompatibility/ClassWriter.php and forgot to rollback. Thanks for pointing this out!

About #37:

1. I changed the return comment on this new patch.
2. IMHO I don't think we should backport this to 9.x. Just focus on D10.

On backporting - it's been good to do as much as we can in 9.x prior to 10.x (we already made a lot of changes along these lines), but I don't we need to worry too much about extracting changes for backport now that 10.x is open (unless there's an additional specific reason to do so).

#3259142 landed, now I'm rerunning #38, hope it passes now.

Looks like a random test fail, restarting test

And @catch beat me to it :)

This looks great. Removing usages and one internal class rather than deprecations as such so good to go in before the alpha.

Committed c022827 and pushed to 10.0.x. Thanks!