* feat: Add execution idAdds an execution id for each request. When the LOG_EXECUTION_ID env var is set, the execution id will be included in logs.

* feat: support disabling execution id logging* Update test_execution_id.py* Update __init__.py* Update __init__.py

* feat: restore defaults present < 3.6.0, but retain customizability* revert the test, too* also restore this assert :)---------Co-authored-by: Jeremy Fehr <jfehrforgithub2@gmail.com>

Co-authored-by: jrmfg <117788025+jrmfg@users.noreply.github.com>

Co-authored-by: jrmfg <117788025+jrmfg@users.noreply.github.com>

needed for security scorecard

…dy timed out (#328)Overhead-free (or at least very cheap).The “timeout” gunicorn config means drastically different things forsync and non-sync workers:> Workers silent for more than this many seconds are killed and restarted.> > Value is a positive number or 0. Setting it to 0 has the effect of> infinite timeouts by disabling timeouts for all workers entirely.> > Generally, the default of thirty seconds should suffice. Only set this> noticeably higher if you’re sure of the repercussions for sync workers.> For the non sync workers it just means that the worker process is still> communicating and is not tied to the length of time required to handle a> single request.So.  For cases where threads = 1 (user set or our defaults), we’ll usethe sync worker and let the regular timeout functionality do its thing.For cases where threads > 1, we’re using the gthread worker, and timeoutmeans something completely different and not really user-observable.  Sowe’ll leave the communication timeout (default gunicorn “timeout”) at 30seconds, but create our own gthread-derived worker class to use instead,which terminates request handling (with no mind to gunicorn’s “gracefulshutdown” config), to emulate GCFv1.The arbiter spawns these workers, so we have to maintain some sort ofglobal timeout state for us to read in our custom gthread worker.In the future, we should consider letting the user adjust the gracefulshutdown seconds.  But the default of 30 seems like it’s worked finehistorically, so it’s hard to argue for changing it.  IIUC, this meansthat on gen 2, there’s a small behavior difference for the sync workerscompared to gen 1, in that gen 2 sync worker workloads will get an extra30 seconds of timeout to gracefully shut down.  I don’t think monkeyingwith this config and opting-in to sync workers is very common, though,so let’s not worry about it here; everyone should be on the gthread pathoutlined above.* fix tests* small test fixesgive up on coverage support for things that are tested in differentprocesses, or in gthread, because it looks like pytest-cov gave up onsupport for these, where as coverage has out-of-the-box support* format* isort everything* skip tests on macthere's something test-specific about how mac pickles functions forexecution in multiprocessing.Process which is causing problems.  itseems somewhere in the innards of flask and gunicorn and macos...since this feature is opt-in anyway, let's just skip testing darwin.* sort tuple of dicts in async tests before assertingcauses flakes sometimes in workflows* use double-quotes* also skip tests on windows - this is all built for gunicorn, there's novalue adding it for windows anyway* skip import on windows* easy stuff* add a few tests for sync worker timeoutsthese shouldn't have changed with this commit

Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>