configure space/time_coinc_far from API, incorporate
voevent changes.

modify the superevent model so that:
 1) coinc_far --> time_coinc_far
 2) new db column: space_coinc far.

These are now available as part of the API response, but the client
code needs to be modified to edit these values in updateSuperevent.

This is going to increase the size of the LVALert
packet. But from what i've seen:

https://dcc.ligo.org/LIGO-T1800079

the network can handle the traffic. I'm going to monitor
playground once it goes live there and make a judgement
call about deciding what to include in production.

by proxy it also gets added to the LVALert. This also addresses:
https://git.ligo.org/lscsoft/gracedb/issues/184

since a user can now just query an

obj['object']['preferred_event_data']['offline']

dict entry.

I still need to add some tests, and will probably have to tweak
conditional logic, but it works so far.

django 2.2.0, django-guardian-2.2.0, new search labels, caching fixes

get_from_env() stores this value as a string, but
django settings needs it as an integer. pages fail to load
otherwise!

From what i can tell, this was never implemented. Fixes this issue:

https://git.ligo.org/lscsoft/gracedb/issues/194

if the 'is_exposed' boolean is 'True', then the superevent is
public. changing the response so that it's 'is_public' would
require more than a two-line change.

In support of: https://git.ligo.org/lscsoft/gracedb/merge_requests/32

Ingests a 'FAR' field in Hz and adds it to the event data model. If
the field is present, then show it in the GRB event table on the
detail page.

This allows for persistent database connections for workers.

Adds KAGRA as a preferred idp on the shib login screen

Adding NOT_GRB and EXT_SKYMAP_READY labels in support of

emfollow/gwcelery!725

From what I can gather, there was a time when likelihood and gpstime
were integers for CWB events, and so there was an explicit casting of
them to integers. Brandon removed gpstime, but left in likelihood
before during ER6. Oops.

KAGRA members send a different ldap group name (ldap_name) but the
current group stsructure doesn't allow for that. This is a pretty
invasive restructuring that basically adds a many-to-one relationship
map different ldap names to the same group. I think the tests are still failing,
but they should be restructured.

It looks like the previous check that determined if the file_version was None is broken in python3:
https://stackoverflow.com/questions/8961005/comparing-none-with-built-in-types-using-arithmetic-operators
So the comparison of log.file_version=None >=0 would error out. I added the conditional to the top of the block and combined a couple of lines.

For S191216ap, the p_terrestrial value was so small:
pastro_values=[('BNS', 0.0), ('NSBH', 0.0), ('BBH', 0.0), ('Terrestrial', 8.427577149405988e-16), ('MassGap', 0.9999999999999991)]

python was converting it to a NoneType, which would then fail when you tried to sort or compare values. So, for this view, convert NoneType probabilities to 0.0.

specifying dataType="float" would cause encoding errors when
passed into voeventlib. this change uses autoconvert for all
float-type data parameters.

The xmldoc write was never being closed on event upload and so
the original copy of the coinc.xml file was never created. Fixed
now.

In testing, it was found that updating external events would result
in a 500 server error when GraceDB was assembling the update LVALert.
The new VOEventParse library was recording three VOEVent fields
as <StringElements> instead of strings, which was failing when the
event was being dumped to json.

Don't override LVALERT_OVERSEER_INSTANCE settings from
envrionment variables.

1) Fixed a 500 Internal Server error when removing labels from events
   that do not exist. Basically the ValueError.message method was
   depreciated in python3; replaced it with a str(error).
2) Bumped version to 2.8.0

Fixed LVAlert server for "test" container, and fixed 500 server error
when sorting p_astro list for the public event page. I think this

https://stackoverflow.com/questions/27776026/lambda-arguments-unpack-error

fixes it.

Reflects new usage of EM_READY and EM_Selected labels in
superevent 2.0.

The server will now return a 400 "bad request" error for RAVEN
createVOEvent calls if:
  1. em_type for the associated superevent is None
  2. em_type for the associated superevent is not a valid graceid
  3. the event associated with em_type cannot be found
  4. the combined_skymap_filename is set, but the file could not
     be found.