This is largely based on PR #550 by @rg663 and aims to resolve #542 (and #420?)

Users added to an allocation must agree to the EULA for the associated resource, if it exists.

This adds PendingEULA and DeclinedEULA statuses to allocation users. An allocation is available to an user if the status of the allocation and the users allocation status are both Active. An allocation may be active for some users added to it, but not all added users based on whether or not they accepted the EULA (if applicable). PI's must accept the EULA to submit an allocation request, where enabled.

This attaches EULA agreements to individual allocations, but EULAs are associated with resources. This means an user has to agree to the EULA for each individual allocation on a given resource.

PIs agree to the EULA when submitting an allocation request.

Some things to consider testing (in addition to those listed in #542):

• users can only accept a EULA for themselves
• users choice is reflected in displayed and available allocations
  • check accounts are generated with appropriate outputs, e.g. try DEBUG=True PLUGIN_SLURM=True coldfront slurm_dump and verify that output matches expectations
  • Note, there are subtleties -- Users with permissions to see all allocations (like admin or director views) will typically see the status of the allocation. This may not reflect their ability to use the allocation.
• users who reject a eula can be removed and re-added to an allocation by a PI/Manager. They will have a new opportunity to accept. Admins can manually reset the check by changing DeclinedEULA -> PendingEULA status.
• resources without a EULA should not require agreements
• setting EULA_AGREEMENT = False should disable eula enforcement. Switching that on/off may result in some unexpected behaviors though.
• Email reminders have been implemented, but we do not currently have a mail service configured to test.