Allow downgrading to 2.11 from 3.x

[ashb]

There were two things blocking this:

1. The revision heads map didn't have any 2.11.x versions in it, so the
   previous implementation of _get_version_revision was only looking within
   the same <major>.<minor> patch version.

   We change it to rely on the fact that our pre-commit checks ensure this map
   is ordered, and iterate over the dictionary reversed, and when we find the
   first thing less than the target revision we use that (direct equal is
   handled already above)

2. The ab_* tables not existing were blocking the migration. Part of this is
   now fixable manually with Create FAB's user/role tables on migration, not only on initdb #54227, but I have decided that since FAB was
   required and the only option in 2.x, so I have decided to just create the
   tables if they are missing

   In order to try and cope with possible future changes I create the tables
   at the latest version and then downgrade to the oldest known revision.

   This is all handled in a reset_to_2_x() method on the FABDBManager, with
   a fallback to just blindly create the tables from the ORM for versions of
   the provider that don't yet have that function.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[ashb]

Hmm the test failures here are interesting -- it's cause downgrade is being called twice, once for the base/airflow-core and once for the DB manager, which is now finding a revision.

Which might mean that db downgrade --to-version was non-sensical before in what it would actually downgrade to for external DB managers.

Bah Humbug.

[potiuk]

Those "external DB managers" is a real pain - I am happy we opposed to take it further for the AWS provider. I'd say the only good way of solving those is to separate it to two commands that have nothing to do with each other and are individually run by the users. Not sure if this is doable now,

[ashb]

@o-nikolas any insight in to this?

[ashb]

My current thought after stepping away from this for a few hours is to change the syntax of db downgrade to be something like:

airflow db downgrade --to-revision FABDBManager=<xxx> <main_revision> 

i.e. turn to-revision from nargs=1 to nargs=+, and then split on = etc.

Thoughts?

[ashb]

Oh! This is just a bad test! The db downgrade path doesn't actually run downgrades for db managers

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker b9cdc3d v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[ashb]

This broke main, I'll revert it for now.