Dev environment: Add settings necessary for https and reverse proxy

[benjaoming]

Why

Depends on: readthedocs/common#176

This setup enables a developer to:

• Run development environments behind HTTPS
• Use a custom production domain and subdomains
• Test developer's own GitHub OAuth applications
• Finally set DEBUG=False via an option for invoke docker.up 🎉

What

Changes to docker-compose setup:

• Storage HTTPS compatibility: Docker container for storage needs additional configuration
• Custom domain w/ https possible: Additional settings to traverse from inv to settings.docker_compose
• New socialauth options in settings.docker_compose to enable https
• New setting to disable a suspicious host check in new unresolver

Changes

This PR was originally intended to add https compatibility to the storage container, but turned out a few more things beyond the inv docker.up --ngrok=custom.dev.example have been necessary

[benjaoming]

(deleted a comment about using AWS_S3_CUSTOM_DOMAIN instead - yes, that worked for my setup with static files storage - but we have a different storage classes for media, so can't use a global setting)

[humitos]

What's the best way to run this PR locally and check that everything works as expected? What's the inv command I should run to spin up the instance?

[benjaoming]

@humitos I forgot to add in the PR description that this depends on readthedocs/common#176

But yes, it would be nice if you can check that it works with your previous usage of --ngrok -- no reason that it shouldn't!

So a full demo would be: inv docker.up --no-django-debug --http-domain=<your-ngrok-domain> --https

Note that --https adds some new stuff that might have worked fine with your ngrok proxy - I have been running with an extra Nginx proxy in front that might have interfered more.

[humitos]

Run development environments behind HTTPS

Is this required for any particular reason? This is the chunk of code that makes me more noise from this PR (touches production code and adds complexity) and I'd try to avoid it unless it's strictly needed for a particular task. I've never required to run our development instance over HTTPS, even when working with GitHub webhooks and other stuffs.

I'd be happy if we split this PR in two and remove from this one the --https option so we can keep discussing that in another PR and we don't block this one.

[benjaoming]

Note to self: We have areas in the code-base using protocol = 'http' if settings.DEBUG else 'https', these should also be fixed when adding --https in another PR.

[benjaoming]

New PRs:

• Dev: invoke options --no-django-debug and --http-domain #10384
• Dev: Support https in development environments #10385