This PR was merged into the 4.4 branch.

Discussion
----------

[HttpClient] fix monitoring responses issued before reset()

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | -
| License       | MIT
| Doc PR        | -

Follow up of #44601

In order to reset the DNS cache, we have to create a new curl-multi handle. But since there might still be responses attached to the previous handle, we need to keep it around to monitor it.

Best reviewed [ignoring whitespaces](https://github.com/symfony/symfony/pull/44625/files?w=1).

Commits
-------

6e529608c0 [HttpClient] fix monitoring responses issued before reset()

This PR was merged into the 4.4 branch.

Discussion
----------

[HttpClient] Don't reset timeout counter when initializing requests

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #44544
| License       | MIT
| Doc PR        | -

Same as #42896 but on initialize.

Commits
-------

8f3bdeb359 [HttpClient] Don't reset timeout counter when initializing requests

This PR was squashed before being merged into the 4.4 branch.

Discussion
----------

curl_multi_exec errors should not be ignored?

| Q             | A
| ------------- | ---
| Branch?       | 4.4 <!-- see below -->
| Bug fix?      | yes
| New feature?  | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       |  <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

curl_multi_exec errors should not be ignored, but i'm not exactly sure how they should be handled either, so i just throw a RuntimeException, any suggestions?

in any case, these errors should be exceedingly rare, the `CURLM_BAD_EASY_HANDLE` / `CURLM_BAD_HANDLE` should only be caused by internal Symfony bugs, and `CURLM_INTERNAL_ERROR` should only be caused by internal libcurl bugs, which leaves CURLM_OUT_OF_MEMORY

Commits
-------

6f66dec437 [HttpClient] Don't ignore errors from curl_multi_exec()

This PR was squashed before being merged into the 4.4 branch.

Discussion
----------

[HttpClient] Double check if handle is complete

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       |
| License       | MIT
| Doc PR        |

This is a forward compatibility fix. We did the same in Guzzle after a comment from bagder.

https://github.com/guzzle/guzzle/pull/2892#issuecomment-945150216

Basically, if libcurl decides to add an other value for `msg`, then our code will break without this PR. The only value for `msg` with current latest version of curl is `CURLMSG_DONE` which means that this is not a bugfix yet.. but it make sure that we respect the libcurl API.

Commits
-------

f35a6ad77e [HttpClient] Double check if handle is complete

Signed-off-by: Alexander M. Turek <me@derrabus.de>

added the php80 polyfill to requirements when necessary

Signed-off-by: Alexander M. Turek <me@derrabus.de>

… for unaffected PHP versions

Signed-off-by: Alexander M. Turek <me@derrabus.de>