Control access to registration_form based on permitted people types

Moving from #1473008: Adding user uid and making email optional.

This issue covers:

• Move access checks from registration_form to access callbacks.
• Implement method to check people types of a Registration entity
• Implement function to check people types a user may register.
• Eliminate 'myself' option if you are already registered
• Disallow access to edit a registration if user does not have permission to edit people type that is currently associated with the Registration.

Reference

There are three 'people types':

• Myself
• Other accounts
• Other person

Implementation

Create registration_access_people():

• It determines what people types a user has access to.
• If the user is creating a registration, then it also checks if the user already has a registration for this entity.

In registration_access:

In CREATE block

1. Determine people types user has access to (registration_access_people())
2. If user has > 0 people types available, then grant CREATE.

In UPDATE block.

1. Determine people types user has access to (registration_access_people())
2. Determine people type that the registration is.
3. If user has access to the people type the registration is, then grant UPDATE.

Change SELECT element in registration_form to use values from helper (registration_access_people())

RE: @attiks on #1473008: Adding user uid and making email optional #32:

You would give anonymous users, the "create TYPE registration other anonymous" permission.

Why?

At one time, a user may not have access to any people types. Hiding the form for zero types is better handled in registration_access.

The attached patch has changed since #1473008: Adding user uid and making email optional.