Rework the TriggererJobRunner to run triggers in a process without DB access

[ashb]

This uses a similar approach to the DAG Parser -- the subprocess runs the
async Triggers (i.e. user code) in a process and sends messages back and forth
to the supervisor/parent to perform CRUD operations on the DB.

I have also massively re-worked how per-trigger logging works to greatly simplify it. I hope @dstandish will approve.
The main way it has been simplified is with the switch to TaskSDK then all (100%! Really) of logs are set as JSON over a socket to the parent process; everything in the subprocess logs to this output, there is no differentiation needed in stdlib, no custom handlers etc. and by making use of structlog's automatic context vars we can include a trigger_id field -- if we find that we route the output to the right trigger specific log file.

This is all now so much simpler with structlog in the mix.

Logging from the async process works as follows:

• stdlib logging is configured to send messages via struct log as json
• As part of the stdlib->structlog processing change we include structlog bound contextvars
• When a triggerer coro starts it binds trigger_id as a paramter
• When the Supervisor receives a log message (which happens as LD JSON over a dedicated socket channel) it parses the JSON, and if it finds trigger_id key in there it redirects it to the trigger file log, else prints it.

Of note: I haven't allowed triggers to directly access or set Xcom, Variables etc. We can add that in future if there is demand.

Testing:

I created a simple test dag:

from datetime import timedelta

from airflow import DAG
from airflow.providers.standard.sensors.time_delta import WaitSensor


with DAG("trigger_test"):
    WaitSensor(task_id="waiter", time_to_wait=timedelta(seconds=90), deferrable=True)

And fired things up in breeze start-airflow

And we can see that the trigger runs and we get logs from the triggerer in the output (The ordering of logs isn't correct, but that is a separate issue)

---

^ 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 newsfragments.

[ashb]

I need to re-examing logs to make sure they still get routed to the right place, and fix all the tests

[amoghrajesh]

Looks good overall, just few comments/qns

[amoghrajesh]

Thanks for addressing my comments, LGTM +1.

Lets get this one in, we might discover issues while testing and we can fix those as they come.

[vincbeck]

Looks good! Massive refactoring on the triggerer side! I'd wait for more reviews given the size of the PR but I could not find anything outstanding :)