Now there are two separate steps - get notifications and
get contacts for those notifications. Makes testing easier.

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.

These tests cover the bugfix in the previous commit.

Based on "feedback" from the low-latency group, the p_astro
and other information which is in the VOEvent files will not be
made available through the API to unauthenticated users. I'm
not sure why.

Needs to work properly with new AuthGroup setup and X509Cert
model changes

This was an exact duplicate of the user model and basically just
provided a simple way to organize robot accounts.  It's not useful
anymore since we'll just use a Group going forward to organize
these accounts.

An X509 certificate should only map to a single user account - we
can't do authentication properly if it maps to multiple, so this
was an obviously necessary change. There are several migrations for
making this conversion in steps.

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.