feat(serializer): denormalize into the declared collection class

[GromNaN]

Q	A
Branch?	main
Tickets	-
License	MIT
Doc PR	-

A property that declares a collection class, such as Doctrine\Common\Collections\Collection, was denormalized into a plain array. The item normalizer kept only the element class and asked the Serializer for Foo[], and PropertyAccessor::setValue() could not write that array into the collection, so the request failed with a 422.

DenormalizerInterface::denormalize() only takes a string type, so the container class cannot be part of the type. The core Serializer carries the element type of a collection in the value_type and key_type context entries. AbstractItemNormalizer now reads the declared container class from the property type and passes it with those two entries, mirroring AbstractObjectNormalizer::getCollectionContainerClass().

The test is testDenormalizeCollectionWithAClassContainer in src/Serializer/Tests/AbstractItemNormalizerTest.php. It asserts the type and the context handed to the Serializer, and the value written back to the object.

class_exists(CollectionDenormalizer::class) keeps the previous behavior on Symfony versions that do not ship the Doctrine collection denormalizer yet. That class is added in Symfony 8.2 (symfony/symfony#66144), and the api-platform constraint symfony/doctrine-bridge: ^7.4 || ^8.0 accepts it. The test covers both branches, so it runs on the current dependencies and on Symfony 8.2 without a change.

A container that is a plain array or iterable keeps the Foo[] type.

The resource-collection branch above (denormalizeObjectCollection) has the same limitation when the elements are API resources. This pull request does not touch it.