Support source creation from consent, remove kit password

[AmandaBirmingham]

Fixes #27, moving the consent endpoint under account and adding a post to enable creation of a human source from a submitted consent form.

Unfortunately, those who live by the shiny new supporting library also die by the shiny new supporting library: although the openapi3 specs support allowing different media types to be passed into a single endpoint (which would have allowed us to add creating a human source from consent form data as another aspect of the /accounts/{account_id}/sources POST that already can take in json data), connexion doesn't currently implement the "multiple media types per endpoint" aspect of openapi3 (spec-first/connexion#655, spec-first/connexion#805 ). Therefore it was necessary to kludge a little. The new /accounts/{account_id}/consent endpoint has a GET that gets consent form html as well as, now, a POST that creates a human source from a submitted consent form (using ONLY the form data media type). I am open to suggestions for better ways to do this.

Because @dhakim87 has ongoing work on source.py, I can't carry through the full implementation of creating a source from the consent form, but I have verified I can parse the incoming data and toss it over to the existing create_source call. Note that, for some reason I can't fathom, connexion sends all form field values to the back end as lists, regardless of the input element type ... e.g.,

{'age_range': ['7-12'], 'consent_child': ['Yes'], 'participant_name': ['a'], 'participant_email': ['b@c.com'], 'consent_witness': ['Yes'], 'obtainer_name': ['Me'], 'consent_parent': ['Yes'], 'parent_1_name': ['b'], 'parent_2_name': ['c'], 'deceased_parent': ['true']}

... Given this, the main thing I do with the form data is ensure each of these lists is really just a single value and then dig it out to make, e.g.,

{'age_range': '7-12', 'consent_child': 'Yes', 'participant_name': 'a', 'participant_email': 'b@c.com', 'consent_witness': 'Yes', 'obtainer_name': 'Me', 'consent_parent': 'Yes', 'parent_1_name': 'b', 'parent_2_name': 'c', 'deceased_parent': 'true'}

... which is what I thought we should get anyway ...

This PR also fixes #27, removing use of kit_password from the yaml api, implementation.py, and kit_repo.py.

[dhakim87]

Change Request: Can you check if you can change the type from array to whatever in the yaml and fix everything coming in as lists in the body?
Comment: Pick either 18-plus or 18+ and let me know which one to use in the database
Comment: Let me know what to store for deceased_parent, needs schema change and migration heuristic most likely.

[dhakim87]

Hmm... I know we aren't going to have kit_password in the future, but does this break migration for existing users? Are our existing kit_name's secure enough to allow everyone to login by kit_name alone until they first register an account with us? I wonder if we need a flag in the db for old_kit or new_kit to enable this...

[AmandaBirmingham]

My understanding was that the decision had been made to take this out, so if that is being rethought, I gotta kick this one to @wasade ....

[AmandaBirmingham]

@dhakim87 , think we need an update on what is required before this PR can be approved. AFAIK, the form field lists issue is fixed (thanks again :) and the 18+ vs 18-plus question has been resolved (in a way that doesn't require changes to this PR). The two remaining issues I see are:

1. Are we really taking out kit_password or no? I think we are still waiting for feedback from @wasade on this?
2. How should deceased_parent be represented? My current bid is to change it from a bool to an enum (so we can still load the existing freaky values but users can't make up new ones). Let me know if this works for you or if you want a different solution ...