feat!: Use more-trusted IP in rate-limiting (#241)

[timmc-edx]

Previously, our rate-limiting code trusted the entire X-Forwarded-For
header, allowing a malicious client to spoof that header and evade
rate-limiting. This commit introduces a new module and setting
allowing us to make a more conservative choice of IPs.

• Create new openedx.core.djangoapps.util.ip module for producing
  the IP "external chain" for requests based on the XFF header and the
  REMOTE_ADDR.
• Include a function that gives the safest choice of IPs.
• Add new setting CLOSEST_CLIENT_IP_FROM_HEADERS for configuring how
  the external chain is derived (i.e. setting the trust
  boundary). Currently has a default, but we may want to make it
  mandatory in the future.
• Change django-ratelimit code to use the proximate IP in the external
  chain -- the one just outside the trust boundary.

Also:

• Change XForwardedForMiddleware to use more conservative choice for
  its REMOTE_ADDR override
• Other adjustments to XForwardedForMiddleware as needed in order to
  initialize new module and support code that needs the real
  REMOTE_ADDR value
• Metrics for observability into the change (and XFF composition)
• Feature switch to restore legacy mode if needed

This also gives us a path forward to removing use of the django-ipware
package, which is no longer maintained and has a handful of bugs that make it
difficult to use safely.

Internal ticket: ARCHBOM-2056

Backported from a251d18

[rgraber]

LGTM