This is explicitly choosing to also parse the X-Forwarded-For header to
yank out this value. Otherwise, the Sentry server relies only on the
REMOTE_ADDR value which will always be wrong when when someone is behind
a reverse proxy.

This logic already exists in some other clients, and this has been
brought up a number of times with users via tickets and support.

Worth noting that it's potentially possible for this value to now be
forged from a user, but the ramification of doing so is so low, it's not
worth putting this behavior behind a feature flag IMO. The worst someone
could do is make some data inside Sentry inaccurate and possibly
confusing. No worse than the current state of the world where the data
is completely inaccurate.

- Implemented in Django via middleware
- Defer empty culprit to server (Sentry deals fills it)
- Implemented Celery as task names
- Cleaned up Django and Celery abstractions to ease testing

Fixes GH-819

@getsentry/python

We're seeing some odd issues with our six module interacting
badly with the six module from other libraries for some users.
The suspicion is that our six module in some cases gets unvendored.
We thus rename it to `raven._compat` (which is also what some
other Python modules do).  We still use six normally for the
tests.

- Update stacktrace truncation code to match server behavior (and defaults)
- Ensure maximum length of each set of variables