…form field type inside array (l-naumann)

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

Discussion
----------

[Mime] Throw InvalidArgumentException on invalid form field type inside array

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Tickets       | n/a
| License       | MIT

Example code:
```php
$f = new FormDataPart([
            'foo' => [
                'bar' => 'baz',
                'qux' => [
                    'quux' => 1,
                ],
            ],
        ]);
$f->getParts();
```

Currently, when you use a disallowed type inside an array, a TypeError is thrown:
` Symfony\Component\Mime\Part\Multipart\FormDataPart::configurePart(): Argument #2 ($part) must be of type Symfony\Component\Mime\Part\TextPart, int given`

This change adds a clearly understandable error message:
`The value of the form field "foo[qux][quux]" can only be a string, an array, or an instance of TextPart ("int" given).`

Commits
-------

08f5d7c [Mime] Throw InvalidArgumentException on invalid form field type inside array

…hen publishing a message. (jwage)

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

Discussion
----------

[Messenger] [Amqp] Handle AMQPConnectionException when publishing a message.

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | Fix symfony#36538 Fix symfony#48241
| License       | MIT

If you have a message handler that dispatches messages to another queue, you can encounter `AMQPConnectionException` with the message "Library error: a SSL error occurred" or "a socket error occurred"  depending on if you are using tls or not or if you are running behind a load balancer or not.

You can manually reproduce this issue by dispatching a message where the handler then dispatches another message to a different queue, then go to rabbitmq admin and close the connection manually, then dispatch another message and when the message handler goes to dispatch the other message, you will get this exception:

```
a socket error occurred
#0 /vagrant/vendor/symfony/amqp-messenger/Transport/AmqpTransport.php(60): Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpSender->send()
#1 /vagrant/vendor/symfony/messenger/Middleware/SendMessageMiddleware.php(62): Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpTransport->send()
#2 /vagrant/vendor/symfony/messenger/Middleware/FailedMessageProcessingMiddleware.php(34): Symfony\Component\Messenger\Middleware\SendMessageMiddleware->handle()
symfony#3 /vagrant/vendor/symfony/messenger/Middleware/DispatchAfterCurrentBusMiddleware.php(61): Symfony\Component\Messenger\Middleware\FailedMessageProcessingMiddleware->handle()
symfony#4 /vagrant/vendor/symfony/messenger/Middleware/RejectRedeliveredMessageMiddleware.php(41): Symfony\Component\Messenger\Middleware\DispatchAfterCurrentBusMiddleware->handle()
symfony#5 /vagrant/vendor/symfony/messenger/Middleware/AddBusNameStampMiddleware.php(37): Symfony\Component\Messenger\Middleware\RejectRedeliveredMessageMiddleware->handle()
symfony#6 /vagrant/vendor/symfony/messenger/Middleware/TraceableMiddleware.php(40): Symfony\Component\Messenger\Middleware\AddBusNameStampMiddleware->handle()
symfony#7 /vagrant/vendor/symfony/messenger/MessageBus.php(70): Symfony\Component\Messenger\Middleware\TraceableMiddleware->handle()
symfony#8 /vagrant/vendor/symfony/messenger/TraceableMessageBus.php(38): Symfony\Component\Messenger\MessageBus->dispatch()
symfony#9 /vagrant/src/Messenger/MessageBus.php(37): Symfony\Component\Messenger\TraceableMessageBus->dispatch()
symfony#10 /vagrant/vendor/symfony/mailer/Mailer.php(66): App\Messenger\MessageBus->dispatch()
symfony#11 /vagrant/src/Mailer/Mailer.php(83): Symfony\Component\Mailer\Mailer->send()
symfony#12 /vagrant/src/Mailer/Mailer.php(96): App\Mailer\Mailer->send()
symfony#13 /vagrant/src/MessageHandler/Trading/StrategySubscriptionMessageHandler.php(118): App\Mailer\Mailer->sendEmail()
symfony#14 /vagrant/src/MessageHandler/Trading/StrategySubscriptionMessageHandler.php(72): App\MessageHandler\Trading\StrategySubscriptionMessageHandler->handle()
symfony#15 /vagrant/vendor/symfony/messenger/Middleware/HandleMessageMiddleware.php(152): App\MessageHandler\Trading\StrategySubscriptionMessageHandler->__invoke()
symfony#16 /vagrant/vendor/symfony/messenger/Middleware/HandleMessageMiddleware.php(91): Symfony\Component\Messenger\Middleware\HandleMessageMiddleware->callHandler()
symfony#17 /vagrant/vendor/symfony/messenger/Middleware/SendMessageMiddleware.php(71): Symfony\Component\Messenger\Middleware\HandleMessageMiddleware->handle()
symfony#18 /vagrant/vendor/symfony/messenger/Middleware/FailedMessageProcessingMiddleware.php(34): Symfony\Component\Messenger\Middleware\SendMessageMiddleware->handle()
symfony#19 /vagrant/vendor/symfony/messenger/Middleware/DispatchAfterCurrentBusMiddleware.php(68): Symfony\Component\Messenger\Middleware\FailedMessageProcessingMiddleware->handle()
symfony#20 /vagrant/vendor/symfony/messenger/Middleware/RejectRedeliveredMessageMiddleware.php(41): Symfony\Component\Messenger\Middleware\DispatchAfterCurrentBusMiddleware->handle()
symfony#21 /vagrant/vendor/symfony/messenger/Middleware/AddBusNameStampMiddleware.php(37): Symfony\Component\Messenger\Middleware\RejectRedeliveredMessageMiddleware->handle()
symfony#22 /vagrant/vendor/symfony/messenger/Middleware/TraceableMiddleware.php(40): Symfony\Component\Messenger\Middleware\AddBusNameStampMiddleware->handle()
symfony#23 /vagrant/vendor/symfony/messenger/MessageBus.php(70): Symfony\Component\Messenger\Middleware\TraceableMiddleware->handle()
symfony#24 /vagrant/vendor/symfony/messenger/TraceableMessageBus.php(38): Symfony\Component\Messenger\MessageBus->dispatch()
symfony#25 /vagrant/vendor/symfony/messenger/RoutableMessageBus.php(54): Symfony\Component\Messenger\TraceableMessageBus->dispatch()
symfony#26 /vagrant/vendor/symfony/messenger/Worker.php(162): Symfony\Component\Messenger\RoutableMessageBus->dispatch()
symfony#27 /vagrant/vendor/symfony/messenger/Worker.php(109): Symfony\Component\Messenger\Worker->handleMessage()
symfony#28 /vagrant/vendor/symfony/messenger/Command/ConsumeMessagesCommand.php(238): Symfony\Component\Messenger\Worker->run()
symfony#29 /vagrant/vendor/symfony/console/Command/Command.php(326): Symfony\Component\Messenger\Command\ConsumeMessagesCommand->execute()
symfony#30 /vagrant/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
symfony#31 /vagrant/vendor/symfony/framework-bundle/Console/Application.php(126): Symfony\Component\Console\Application->doRunCommand()
symfony#32 /vagrant/vendor/symfony/console/Application.php(324): Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand()
symfony#33 /vagrant/vendor/symfony/framework-bundle/Console/Application.php(80): Symfony\Component\Console\Application->doRun()
symfony#34 /vagrant/vendor/symfony/console/Application.php(175): Symfony\Bundle\FrameworkBundle\Console\Application->doRun()
symfony#35 /vagrant/vendor/symfony/runtime/Runner/Symfony/ConsoleApplicationRunner.php(49): Symfony\Component\Console\Application->run()
symfony#36 /vagrant/vendor/autoload_runtime.php(29): Symfony\Component\Runtime\Runner\Symfony\ConsoleApplicationRunner->run()
symfony#37 /vagrant/bin/console(11): require_once('...')
symfony#38 {main}
```

TODO:

- [x] Add test for retry logic when publishing messages

Commits
-------

f123370 [Messenger] [Amqp] Handle AMQPConnectionException when publishing a message.

…cing keys (Brajk19)

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

Discussion
----------

[Validator] UniqueValidator - normalize before reducing keys

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        |
| License       | MIT

In symfony#42403 checking for uniqueness of certain collection keys was enabled. Method `UniqueValidator::reduceElementKeys` removes all keys which are not specified.
Problem is that this happens before normalization, which in my opinion is not great because that method accepts array argument and if i have some object (DTO), TypeError will be thrown.

Example:

```php
class ParentDTO
{
    /**
     * `@var` ChildDTO[]
     */
    #[Assert\Unique(
        normalizer: [ChildDTO::class, 'normalize']
        fields: 'id'
    )]
    public array $children;
}
```

```php
class ChildDTO
{
    public string $id;
    public string $name;

    public static function normalize(self $obj): array
    {
        return [
            'id' => $obj->id,
            'name' => $obj->name
        ];
    }
}
```

Because normalization will happen after `reduceElementKeys` this will be thrown:
`TypeError: Symfony\Component\Validator\Constraints\UniqueValidator::reduceElementKeys(): Argument #2 ($element) must be of type array, ...\ChildDTO given, called in .../UniqueValidator.php on line 48`

If `$element = $normalizer($element);` is executed before `reduceElementKeys` it would enable using Assert\Unique with array of objects when correctly normalized

Commits
-------

77df90b [Validator] UniqueValidator - normalize before reducing keys

…s string similar to username/password (glaubinix)

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

Discussion
----------

[Security] Validate that CSRF token in form login is string similar to username/password

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | See exception output below
| License       | MIT

<!--
Replace this notice by a description of your feature/bugfix.
This will help reviewers and should be a good start for the documentation.

 - Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
 - Never break backward compatibility (see https://symfony.com/bc).
-->

Fixes
```
Uncaught Error: Symfony\Component\Security\Http\Authenticator\Passport\Badge\CsrfTokenBadge::__construct(): Argument #2 ($csrfToken) must be of type ?string, array given, called in /vendor/symfony/security-http/Authenticator/FormLoginAuthenticator.php on line 88
```

Commits
-------

b501bba [Security] Validate that CSRF token in form login is string similar to username/password

…alexandre-daubois)

This PR was merged into the 5.4 branch.

Discussion
----------

[HttpClient] Fix cURL default options for PHP 8.4

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | -
| License       | MIT

PHP 8.4 brings a change in ext/curl (php/php-src#13291) that requires `CurlResponse` to be updated. Curl callbacks cannot be set to null anymore and requires real callable.

Here is (one of) the CI error it fixes:

```
10) Symfony\Component\HttpClient\Tests\CurlHttpClientTest::testGzipBroken
Failed asserting that exception of type "TypeError" matches expected exception "Symfony\Contracts\HttpClient\Exception\TransportExceptionInterface". Message was: "curl_setopt_array(): Argument #2 ($options) must be a valid callback for option CURLOPT_PROGRESSFUNCTION, no array or string given" at
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/CurlResponse.php:175
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Internal/Canary.php:32
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/TransportResponseTrait.php:90
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/TransportResponseTrait.php:218
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/CommonResponseTrait.php:68
/home/runner/work/symfony/symfony/src/Symfony/Component/HttpClient/Response/CurlResponse.php:232
/home/runner/work/symfony/symfony/src/Symfony/Contracts/HttpClient/Test/HttpClientTestCase.php:1113
```

Commits
-------

cc0b957 [HttpClient] Fix cURL default options