If the sponsor writes a valid but non-existent email in a guest invite
we retried sending this email indefinitely. Instead of leaving django q
in an endless loop, we now send an email to the sponsor warning about
the problem instead.

Since we may not want to enable the identity check, it must be
togglable. This commit adds environment variable
REACT_APP_ENABLE_IGA_CHECK for toggling the check in the frontend, and
django settings variable IGA_CHECK for toggling the check in the
backend.

Move serializers only used by gregui.

Queries iga for an external id matching ours. If a match is found, the
name of the owner is returend. Otherwise we return null. Uses the new
iga module to fetch the data.

Was removed by mistake at some time in the past. Introduced a few tests
to ensure that things work as expected.

Resolves: GREG-223

Verify that the backend accepts unicode for text fields and that it
survives to the database and back again

Switched from caring about the output to only check the number of
results since that's what we really care about

If someone that already exists in greg follows an invite, we are kind
enough to give the new role to the existing person. This introduced a
security risk if the invitation was actually meant for someone else.

Because of this situation, we introduce a security mechanism where we
disable the invitationlink if the name of the existing person is too
different from the name used in the invitation.

Resolves: GREG-166

If the user logs in through the frontpage we now check if they have
completed the registration process. If they have completed it halfway
before, we find their info through the GregUserProfile of the user and
redirect to the register page. If we dont find any profile connected to
the user they are treated as anonymous users as before.

Resolves: GREG-164

Resolves: GREG-173

Issue: greg-105

Issue: greg-112

It has been decided that a sponsor at a unit should have access to all
roles at that unit. This includes all units accessible through
hierarchical access.

Resolves: GREG-150

Dates can now be changed after they have started and ended. This means
that there is no situation which needs disabling the input fields, and
disabling has been removed.

Start and end date can now be in the past. The following rules apply:
 - Start dates can be any date in the past, and no more into the future
   than the max days property of the role type.
 - End dates follow the same rules
 - End dates must be equal to or later than start date.

Notification publishing has been reviewed to ensure duplicate
notifications are not created when start or end date is today.

Resolve: GREG-148

- Combine the /invite and /invitelink endpoints into one
- Return error messages from the backend
- Handle errors in the frontend
- Lower number of queries ran when calling the userinfo endpoint