add support for --proxy-headers and friends in runserver

[sxpert]

• Your OS and runtime environment, and browser if applicable not applicable

• A pip freeze output showing your package versions

  argon2-cffi==23.1.0
  argon2-cffi-bindings==21.2.0
  asgiref==3.8.1
  attrs==23.2.0
  autobahn==23.6.2
  Automat==22.10.0
  certifi==2024.2.2
  cffi==1.16.0
  channels==4.0.0
  constantly==23.10.4
  cryptography==42.0.5
  daphne==4.1.0
  Django==5.0
  django-minio-storage==0.5.7
  django-parler==2.3
  hyperlink==21.0.0
  idna==3.6
  incremental==22.10.0
  minio==7.2.5
  pillow==10.2.0
  psycopg==3.1.18
  psycopg-c==3.1.18
  pyasn1==0.6.0
  pyasn1_modules==0.4.0
  pycparser==2.21
  pycryptodome==3.20.0
  pyOpenSSL==24.1.0
  service-identity==24.1.0
  setuptools==69.2.0
  six==1.16.0
  sqlparse==0.4.4
  Twisted==24.3.0
  txaio==23.1.1
  typing_extensions==4.10.0
  urllib3==2.2.1
  zope.interface==6.2

• What you expected to happen vs. what actually happened being able to use

  $ ./manage.py runserver --proxy-headers ${SERVER_IP_PORT}

• How you're running Channels (runserver? daphne/runworker? Nginx/Apache in front?) runserver

• Console logs and full tracebacks of any errors runserver command barfs with invalid option.

[carltongibson]

The runserver command is only for use in local development, not to be used with a proxy. (If you need to test particular headers, I'd suggest an ASGI middleware.)

[sxpert]

I'll send a PR... it's not that hard to implement.

[carltongibson]

I think you misunderstand. This isn't in scope for the runserver command. (You're welcome to implement your own version if you need it.)

[sxpert]

ridiculous answer calls for ridiculous counter-measures.