Admin endpoints

The administrative interface needs additional ways to get information in and out of the database. The The following are the endpoints known about at this time. A numbering of 1-3 is used to indicate priority where 1 is most urgent, 3 is least urgent.

Sample search:
- [x] (1) `GET /admin/search/barcode/{barcode}` returning detailed information about the sample including sample type, kit ID, account ID, name, email, etc
- [x] (3) `GET /admin/search/kit_id/{kit_id}` returning detailed information about the kit including the samples contained, account ID, any source IDs, etc
- [x] (2) `GET /admin/search/email/{email}` returning detailed information about the associated account including kits and sample information

Sample scanning will also need the `GET .../{barcode}` endpoint implemented for search. It will also need:
- [x] (1) `POST /admin/scan/{barcode}` with a body containing `{'sample_status': , 'technician_notes': str}`. These data should be recorded in the `barcodes` schema, and a `scan_date` entry in the database should get a timestamp of `NOW`. This recorded information should be obtainable from the search `GET .../{barcode}` described above. Sample status values are: `{not-received, sample-is-valid, no-associated-consent, no-registered-account, sample-has-inconsistencies}`

Kit creation:
- [x] (2) `POST /admin/create/kits` with a body containing `{'number_of_kits': , 'samples_per_kit': , 'kit_id_prefix': | None, 'projects': <[str]>}`. This should trigger the addition of entries into the `barcodes` schema. If "American Gut Project" is one of the project names, appropriate entries should be created in `ag.ag_kit` and `ag.ag_kit_barcodes`. If `kit_id_prefix` is specified, that string should be prefixed to all created kit IDs. Barcode IDs created *SHOULD NOT* consist only of digits, but should always include a non-numeric character to avoid programs like Excel accidentally assuming these are numbers. This endpoint should return `{'created': [{'kit_id': , 'sample_barcodes': <[str]>, 'kit_uuid': ]}`. The `kit_uuid` needs to be safe to share; this ID will be visible on the outside of the kit. All created samples get an initial sample status of `not-received`.
- [ ] (2) `PUT /admin/projects/{kit_id}` with a body containing `{'projects': <[str]>}` to update the project associations with a kit.

Kit tracking. We will have the ability to obtain the FedEx tracking information, as well as the exact address a kit was shipped too. Recording this will be very useful.
- [ ] (3) `POST /admin/shipping` with a body containing `{'shipped': [{'kit_uuid': , 'fedex_tracking': , 'address': }`. This information should be stored within the `barcodes` schema. The exact specifications of what we will be getting here have not been provided, other than we will get `kit_uuid` and `fedex_tracking`.
- [ ] (3) `GET /admin/shipping/kit_uuid/{kit_uuid}` should return the `{'fedex_tracking': , 'address': }`

Sample pulldown. We need to be able to construct QIIME compatible sample metadata from what's stored in the database:
- [x] (2) `GET /admin/metadata/{barcode}/{survey_template_id}` should return {'sample_id': , 'host_subject_id': , : , ...}` for the corresponding survey_template. The `host_subject_id` needs to be a unique identifier for the individual; the existing service used SHA512 with a combination of the `ag_login_id` (which is now the `account_id`) and the `participant_name` from consent. The `QUESTION_SHORTNAME_X` entries from the `ag.survey_question` table, and the value should be the value for their response.
- [x] (3) `GET /admin/metadata/{barcode}` should pull down metadata for all surveys associated with the barcode.

Database statistics:
- [ ] (3) `GET /admin/statistics/projects` should return `{'projects': [{'project_id': , 'project_name': , 'number_of_samples': , 'number_of_kits': }`
- [ ] (2) `GET /admin/statistics/project/{project_id}` should return `{'project_name': , 'number_of_samples': , 'number_of_kits': , 'number_of_samples_scanned_in': , 'sample_status_counts': {'sample-is-valid': , ...}}`. The `sample_status_counts` field corresponds to the scanning status enum noted in scanning above, and is the number of samples in each category.
- [ ] (3) `GET /admin/statistics/microsetta` should return similar detail to the `project_id` specific endpoint, however it should also include detail on the number of surveys filled out, and basic demographic detail such as number of sample by gender, number of samples by country, etc.
- [ ] (2.5) `GET /admin/statistics/covid` should return summary detail from the pending COVID questionnaire, including sample / person counts per US zipcode.

The issue names no files or tests; begin by reviewing the existing admin endpoint patterns and the barcodes and ag schemas referenced in the requirements. The remaining unchecked project, shipping, and statistics endpoints are done when they accept the specified inputs, persist the required data, and return the listed summaries, though shipping specifications are incomplete.

Written by the indexing model from the issue text.