Drop temporary migration code

[AdrienClairembault]

Checklist before requesting a review

• I have performed a self-review of my code.

Description

This code was supposed to help developers work on different versions of the native forms feature without resetting their database too often.
In the end we still reset our databases all the time and this become more work to maintain when adding new feature so we should probably drop it now even if the database schema is not yet final for this feature.

[trasher]

Well... This is the way to proceed globally. I'm not against that, even if I do not always reset a fresh database (that means lost of all configuration, adn I often prefer to keep it).

I'm not against a change, but this should be clear we no longer use that way to proceed (maybe should we drop a line in developer docs anyway).

[trasher]

Also, I guess we must keep at least a par tof migrations, so users using released alphas can upgrade (dunno if removed code affects that).

[AdrienClairembault]

I'm not against a change, but this should be clear we no longer use that way to proceed

I feel like this is the opposite, it's always been this way: database migration are expected to work correctly only when you migrate from one official version to another.
If you migrate from dev/alpha/beta, sure it will work most of the times but you risk having an incomplete database especially for big features that were developed over many months.

I remember there was a lot of support tickets with weird databases issues during the GLPI 10 migration because of this...
Maybe we could forbid database migration from unofficial versions unless the environnement is development ?

I agree that is should not be the case and that we can do a lot better than that but it requires reworking the ways our migrations work (multiple individuals migrations per version + down/up instructions) and that wont be done for GLPI 11 (I think @cedric-anne already has plans for this btw, probably for GLPI 12 then).