[fix] Mapping

[subiabre]

There was a significant gap between resources coming from Entities and resources (proper) coming from ApiResources.

To quickstart the v4 prototype we worked with entities as API resources, super charging them with #[API\...] attributes and other API Platform goodies, however this was not sustainable in the long term, the problem with this approach started surfacing with two of the resources:

• Accountings are resources that can be owned by a number of other resources. They have a polymorphic relationship with their owner. This is a concept that does not exist in Doctrine-land, and the Accounting entity has several owner properties, one for the type of owner it has, and several others, each one for the actual owner it has. Outputting this in the API is highly inconvenient, hard to document and represent, and we could simply do better.

• Gateways are resources that do not exist in Doctrine-land, at all. They do not come from any database that the app connects to, they come from the codebase itself, these resources represent concrete, available code implementations for processing charges and checkouts with an specific payment gateway or mechanism.

We were getting by with custom state providers for the Gateways and Accountings, but the gap snowballed exponentially with the introduction of GatewayCheckout and GatewayCharges, which are entities, for they are records that need to be stored in the database, but they relate Accountings and Gateways, from the ApiResource world, with Entities.

That is when serialization problems start to arise, as API Platform was trying to serialize Accountings as Resources, but then reading objects which specified an Entity Accounting. Along with other problems under the hood, such as context changes and central object uncertainty.

To avoid this the solution is to keep both domains separated, and specifying the conversion steps from entites to resources and the other way around. This allows us to be in control of the data flow and makes API Platform avoid the problems previously mentioned. However this also makes us now responsible for creating and maintaining A LOT of new code as we now need an additional DTO for each Entity (the ApiResource), custom state providers and processors, and mapping classes for the providers and processors to know how to convert from entity to resource.

This PR aims to minimize that amount of code by:

• Adding the jolicode/automapper library to handle the mapping.
• Adding generic ApiResourceStateProvider for resources without custom data retrieval from doctrine and/or mapping.
• Adding generic ApiResourceStateProcessor for resources without custom data processing and/or mapping.