[management] Plans data storage reliability improvment

[ppgravitee]

Plans data are duplicated in APIM database. They are stored in plans table and in apis table, column "definition". We have to ensure that both sides are identical, and modify one table each time we modify the other one.

That makes the application hard to maintain, and brought a lot of bugs (for example #6595, #6042).

This ticket is an improvement to increase maintnability and reliability, By stopping to duplicate plans data, and store them in only one table.

From our spike on 19/05 (https://github.com/gravitee-io/issues/issues/6662), we agreed that :

• We keep storing plans data in the plans DB collection
• We stop storing plans data in the definition field of apis DB collection

To acheive that, we have to (not exhaustive) :

• [x] create e2e tests before any change, to ensure non regression, mainly on gateway events
• [x] discuss with acrhi team to validate solution and check impacts on k8s operator
• [x] split api definition used by gateway (io.gravitee.definition.model.Api) containing plans, from MAPI definition containing no plans, which is stored in apis DB
• [x] be able to create easily a GW definition, providing a MAPI definition + a list of plans
• [x] implement transformation of MAPI definition to GW definition each time we need (for example when sending an event to the gateway)
• [x] cleanup all the plan management stuff that re-write api definition. For example, in PlanService.create
• [x] refactor the way we save the plans using the PUT /apis/[id] endpoint, for example when saving in the designStudio

[ppgravitee]

this is now ready to test. It brings no new feature but is a big refactoring, for which we have to ensure non regression on everything related to :

plans flows (platform flows, api flows and plan flows)