Fix #1159: try Granian

[leplatrem]

Fix #1159

Notes for deployment:

• GRANIAN_TRUSTED_HOSTS would have to be set for X-Forwarded-Host to be read (used in redirections)
• Prometheus metrics scraped on localhost:9090

[alexcottner]

It looks like the web server is hanging and not returning responses with granian much of the time. I think we have a compatibility issue between kinto and granian's wsgi implementation.
Example request:

curl --request GET \
  --url 'http://localhost:8888/v1/buckets?_sort=-last_modified' \
  --header 'Authorization: Basic dXNlcjpwYXNz'

This just hangs forever for me. The root v1 response seems to work most of the time, but not every time.

I don't have more time to dig into it at the moment. I tried updating uvicorn just in case that was causing issues too, but no change.

[alexcottner]

I can't make this work consistently locally. I'm not sure why, but it's very flaky with responses. The logs indicate it's doing the work, but then it doesn't return a response.

[leplatrem]

@alexcottner removing the wrapper seems to fix the issue.
We would have to be careful when rolling this out though, because fo forwared-hosts and redirections

[leplatrem]

Spoiler: it doens't

[leplatrem]

  Root Cause

  The browser tests were hanging because of a postgres deadlock specific to Granian's multi-threaded
  model:

  1. kinto defaults transaction_per_request=True, meaning postgres writes are managed by Pyramid's
  transaction manager (pyramid_tm) and committed at the end of each HTTP request.
  2. auto_create_resources fires on the ApplicationCreated startup event — outside of any HTTP request
  context, so pyramid_tm never commits those postgres writes. The INSERTs for main-workspace,
  main-preview, etc. were left in an idle in transaction state indefinitely.
  3. When the test's create_bucket(main-workspace) request arrived, a second postgres connection tried
  to INSERT the same row and blocked waiting for the open transaction to commit or rollback — deadlock.
  4. Why not uWSGI? uWSGI used multiple processes, each with their own postgres connections. With
  Granian's single-process multi-threaded model, _CLIENTS (kinto's module-level dict) is shared, so both
   the startup event and request threads share the same connection pool.

  Fix

  In auto_create_resources, wrap the resource creation loop in with transaction.manager: to ensure the
  postgres writes are explicitly committed when running outside of a Pyramid request context.