This is not needed anymore with the changes to the group infrastructure
which add an optional 'ldap_name' to groups whose membership should be
managed by LDAP queries and shib sessions.

ligoauth.models.AuthGroup is an enhanced version of the builtin Django
Group model. We add useful attributes like a description, ldap_name,
and Tag.  These can be used to abstract things that are presently
handled manually, like inheriting membership from an LDAP group or
allowing access to view log messages/files with a specific Tag.

I ran some tests comparing this multi-table inheritance setup to
adding a OneToOneField and loading it with/without select_related.
After 1K trials, the DB query times looked comparable and didn't
require multiple queries for this arrangement, so the convenience
seems to be worth it.

The commit creates the model and populates an instance for existing
each existing Django Group.

When applied, this makes a view publicly available *if* the
settings.UNAUTHENTICATED_ACCESS switch is True; otherwise you
must be authenticated. This will be useful to propagate to
most other views to make this settings switch globally effective
at some point.

These settings were previously handled in settings/container/production.py,
but we want to do some testing and I don't see any issues with having
them in the base container settings (settings/container/base.py).

Instead of looping over EmailMessage.send() calls, we now get the
email backend and send a list of messages. Note that the backend
sends the messages individually still but this cuts out some of the
overhead.

Not feasible to use multiple DBs for read or write operations at
present. We're going to have to revisit this at some point. We leave
most of the code in place but commented out.

Separate phone and email contacts, add verification of contact
information, improve views and forms.

Since the web view makes a few API requests to load log messages and
other content, we have to allow more requests. Also, it sounds like
users at a university might all appear to be on the same IP address,
so we want to try to account for that.

Not working as expected, so we are going to have to revisit this
feature in the near future.