[github-actions]

First off: why is this needed, wasn't loops landed and working? "Yes, but."
Part of the goal with the data-modelling changes for task loops (AIP-111)
is to support dynamic graphs (AIP-113) and other dynamic things, such as
choosing to allow loops inside loops (currently a parse error), with no future
migrations or data modelling changes needed. This change lets us enable these
features without expensive recursive queries in TIDep evaulation etc. And why
now? By getting this change in before 3.4.0 enters the RC stage, while we can
still change the migration "at zero-cost". And adding it as a migration in 3.5
would involve a (possibly costly) migration.

So the meat of the change:

Finding the task instances that sit inside one iteration of a loop currently
means finding every region of the loop's fork chain (a fork is when a loop is
cleared part way through and some iterations run a-fresh), plus everything
nested under that iteration, however deep. The previous lookup resolved those
region ids with two recursive CTEs and then passed them to the task_instance
query as literal lists. The nested list holds every region under the
iteration, whichever task is being read, so once something under an iteration
can fan out again (nested loops, or dynamic graphs inside a loop) its size
grows with the product of those widths. Every lookup hits this path: the
scheduler's trigger-rule check of a loop task repeats it on each pass until
the task is ready, and every XCom read from inside a loop pays it on the API
server. Measured with 5,000 regions under one iteration, a lookup that returns
one row took about 30 ms on PostgreSQL and MySQL, almost all of it building,
sending and parsing the list; with 50,000 it took about 550 ms.

Two columns on dynamic_region lets us get the same result but without
recursion. family_root_id is the id of the first region of a fork chain, so
a chain is one equality column comparisson. path contains, for each ancestor
from the top, its family root and the index the region sits at inside it, so
everything under one iteration of a loop shares a byte prefix and is one range
of an index. The lookup becomes a UNION ALL of two joins from task_instance
to dynamic_region, each driven by its own index; a single OR across the two
legs gives the planner no such choice. Its cost no longer depends on how many
regions sit under the iteration. The hook that fills the columns rejects a
fork whose parent differs from its source's, because both the family equality
and the prefix range rely on every member of a chain sharing one position.

Region inserts are rare next to task instance reads and writes, so the hook
and the two extra indexes cost comparitavely little.

The columns are NOT NULL so that raw inserts which skip the ORM fail loudly
instead of writing rows the lookup would silently miss. They are added to the
migration that creates dynamic_region, which has only shipped in a beta, so no
backfill is needed. A 3.4.0b1 database already ran that migration without them
so users in that situation will need to downgrade to 3.3 and upgrade again,
or reset the database. Nesting is capped at ten ancestors, which sets the
200-byte path width on MySQL. The cap is a chosen bound rather than an index
limit, and authoring already rejects nested loops, so current real depth is far lower.

In order to allow more easily resizing this column on MySQL in the future if
we want or need to, the length needs to be over 255 bytes (as InnoDB stores
VARBINARY with shorter values with a 1 byte length prefix.) So we have chosen
300, allowing 15 levels, such that we can change it in future with a meta-data
only storage change. Regardless of max length of column, all DBs only use as
much storage as needed (+ size counter).
(cherry picked from commit 6a925a8)

Co-authored-by: Ash Berlin-Taylor ash@astronomer.io