Switch to symfony/http-client

There was also a recent issue that I can't find anymore that was about only depending on the psr standard interfaces, but we still need an actual implementation too.

Did we already check if symfony/http-client supports the special trickery we need for our tests?

From the Drupal Commerce side of things, this is a huge change. Most of our integrations use Guzzle. Most of the SDKs use Guzzle. If we can have Drupal only rely on the interfaces versus the client, then I guess that is OK. I don't think anything would break, but Guzzle is still going to be present. It definitely has impact in our microcosm.

This is also related to the wider Symfony 4 issue #2937984: [META] Symfony 4.0 compatibility

Link to Guzzle issue about PSR-18 https://github.com/guzzle/guzzle/issues/2186

8.8 does not have a minimum PHP version of 7.1.3. PHP 7.0 is still supported. The minimum version is 7.0.8, and it will remain so in 8.8 and quite possibly until 8.9's EOL.

8.8 does not have a minimum PHP version of 7.1.3. PHP 7.0 is still supported. The minimum version is 7.0.8, and it will remain so in 8.8 and quite possibly until 8.9's EOL.

Just noting that this is still true, but that as of #2917655-44: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 and #2917655-48: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4, it seems somewhat likely that Drupal 8.9 will require PHP 7.1. Still not decided though.

Quoting #3039047-18: Adopt php-http/guzzle6-adapter 2.x to get PSR-18 support without losing Guzzle's async support verbatim:

The #1 concern raised her so far is that Guzzle offers capabilities (specifically, async request handling which enables network concurrency) that we consider important or even essential, that PSR-18 does not prescribe nor guarantees. Meaning that if we were to move to a PSR-18-only API, we'd lose access to those capabilities.

The PSR-18 announcement blog post at https://medium.com/php-fig/psr-18-the-php-standard-for-http-clients-3254... explicitly acknowledges this. The reason: there is no PSR for promises. Once a PSR for promises exists, a new PSR will be created that extends PSR-18 with async support.

Nothing seems to be happening in https://github.com/guzzle/guzzle/issues/2186 nor in https://github.com/guzzle/guzzle/pull/2122 primarily because https://github.com/php-http/guzzle6-adapter already exists, and PSR-18 itself is incapable of providing the full feature set that Guzzle has (notably, again, async support).

The https://symfony.com/blog/new-in-symfony-4-3-httpclient-component provides multiple clients: a native one, a curl-based one (which supports parallel/async requests) and a PSR-18 one. The PSR-18 one again does not have async support. So moving to that would still leave us in the same place, while being more disruptive than only adopting https://github.com/php-http/guzzle6-adapter for getting PSR-18 support.

So, given the inability to keep our feature set if we move to PSR-18 (and as comments show there's clear needs for those features), I propose to add a dependency on php-http/guzzle6-adapter instead. That seems to be the only workable solution.

I propose to mark this as a duplicate of that issue.

Based on https://github.com/guzzle/guzzle/issues/2358, I agree with Wim. They are continuing their rock-solid BC and security policy, and they'll support Guzzle 6 even after a theoretical Guzzle 7 is released. Their one caveat was needing PHP 7.0+, which is fine for us.

There's the option to re-evaluate the Symfony component in the future when it's more mature and feature-complete, but let's stick with Guzzle for now.