Upgrading a patch version should not make breaking changes to the Metadata DB

[NBardelot]

We've had the case with an Airflow 2.9.1 instance, where the instance's Docker images were mistakenly upgraded to 2.9.2. When we tried to rollback the Docker image to 2.9.1, we have errors occuring because the DB upgrade cannot be rollbacked (see #35357 where @lifayt had the very same issue).

My points:

• DB migration rollback is not guaranteed, and I have no issue with that (it's hard to implement safely, and there is not real use-case in the first place) ;
• but DB migration should be tied to a minor version of Airflow, not to patches.

The arguments are:

• if a change happens to the DB schema, it should obviously not be a patch
• if a fix requires changes to the DB content, then it is not a "migration" per se, but a data fix, and it should not block a rollback to a previous patch of the same minor version of Airflow, since the functional specification of the DB has not changed

Thus, I'd like to propose the idea that migration and fixes should be split into two different kinds of processes (which means two different Jobs in the case of the Helm chart): migration jobs and patch jobs. And if possible, a simplified upgrade path can involve the migration job + pre/post patch jobs (depending on the source and target version of Airflow).