Add support for unregistered form submission after email verification

[signebedi]

Anonymous form submission can probably be configured in an individual form's __config__ dictionary. I envision it having two configurations. One is a config called unregistered_submission_enabled, which is a bool that defaults to false. And then the other is an enum called unregistered_submission_method, which can either be email_validated or open, with email_validated being the default. email_validated means that users have to go through a step of verifying their email to get a unique link that will allow them to submit the form. open just means that the form is totally open and that a random set of characters will be created to represent the user who's submitting the form anonymously. The problem with the open approach is that it will break assumptions about the API requiring an API key... but, we'll see and maybe implement this in a follow on feature.

If it is enabled, we will also want to add a metadata field called form_submitted_unregistered, which defaults to false, but when set to true, will stop the UI from rendering links to usernames in the created_by and last_edited_by fields.

Another option could be to create a user on email verification. What that'll do is it'll attempt to create a new user for the user submitting a request automatically and require them next time they log in to create a new password. But I don't know whether this will be too messy to implement. For example, by devising username rules. But I think it's easy enough to take the username portion of a person's email, try to make that a username, and if there's already a username with that name, we just affix a random digit to the end of it. We can make this another option, called email_validated_create_user.

[signebedi]

Add support for open unregistered form submission As a follow on to #357, we should think though how to implement open form submission without breaking core assumptions. open just means that the form is totally open and that a random set of characters will be created to represent the user who's submitting the form anonymously. The problem with the open approach is that it will break assumptions about the API requiring an API key... but perhaps we can resolve this problem by generating a single_user_api_key for open users. We can also still require them to enter their emails and, instead of sending a link to their emails, simply redirect them in the UI....

[signebedi]

One of the immediate problems with the single use API scope is that it potentially gives a user scope access to the WHOLE API, when in fact I think we only want it to provide access to the CREATE_FORM API route... So, we should consider moving this logic into the route itself, if we deem the risk provided by an unbounded API key scope to be sufficient to warrant the additional boilerplate and complexity...

We could fix this by pointing dependencies=[Depends(api_key_auth)] in the /create route to point to a separate api_key_auth function that allows single use keys, while every other route does not.

[signebedi]

Add support for sharing forms with people by email This can be an option in the form config dictionary that, when set to true, allows you to share the form with a user via email. It should inherit the unregistered_submission_method - that is, if it is email_validated_create_user, then we create the user and email them, if it is email_validated, then we simply send it. This could, in fact, just wrap the unregistered form submission process by enabling users to share forms via a UI click interface. Alternatively, we can make this a group permission. This would mean using probably the same route for admins as regular users... The share symbol would probably be: https://icons.getbootstrap.com/icons/share/.