* feat: Add execution id

Adds 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 for
sync 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 use
the sync worker and let the regular timeout functionality do its thing.

For cases where threads > 1, we’re using the gthread worker, and timeout
means something completely different and not really user-observable.  So
we’ll leave the communication timeout (default gunicorn “timeout”) at 30
seconds, but create our own gthread-derived worker class to use instead,
which terminates request handling (with no mind to gunicorn’s “graceful
shutdown” config), to emulate GCFv1.

The arbiter spawns these workers, so we have to maintain some sort of
global timeout state for us to read in our custom gthread worker.

In the future, we should consider letting the user adjust the graceful
shutdown seconds.  But the default of 30 seems like it’s worked fine
historically, so it’s hard to argue for changing it.  IIUC, this means
that on gen 2, there’s a small behavior difference for the sync workers
compared to gen 1, in that gen 2 sync worker workloads will get an extra
30 seconds of timeout to gracefully shut down.  I don’t think monkeying
with 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 path
outlined above.

* fix tests

* small test fixes

give up on coverage support for things that are tested in different
processes, or in gthread, because it looks like pytest-cov gave up on
support for these, where as coverage has out-of-the-box support

* format

* isort everything

* skip tests on mac

there's something test-specific about how mac pickles functions for
execution in multiprocessing.Process which is causing problems.  it
seems 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 asserting

causes flakes sometimes in workflows

* use double-quotes

* also skip tests on windows - this is all built for gunicorn, there's no
value adding it for windows anyway

* skip import on windows

* easy stuff

* add a few tests for sync worker timeouts

these shouldn't have changed with this commit

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