Add support for CTMS

[tomsaleeba]

Requirements:

• added content negotiation support so the Accept header is used to determine if image or metadata is returned
• create endpoint that accepts (POST) Camera Trap Metadata Standard (CTMS) records
• create endpoint that allows updates to existing CTMS records (potentially just POST over the top of existing)
• deploy MongoDB instance to K8s that will store the CTMS records
• implement JSON schema validation against supplied CTMS records
• consider creating a profile (subset) of CTMS if we don't need all the fields

For this implementation, we want to lay the ground work for a decent auth system. For a typical deployment that will support many tenants, we expect to have:

• a single mongo instance (or a single replicated cluster if required)
• one or more ImageRepo pods, scaled horizontally for load-balancing
• support for multiple tenants (logical divisions in the app where one tenant cannot see another's data)
• authentication/authorisation where a client can access their tenant
• revocation of access for keys. Reissuing of keys should maintain access to the original tenant

Use cases:

1. tenants are separated The tenant 1 user POSTs an image to the system at /images/image1.png. tenant 1 user gets the image at /images/image1.png. tenant 2 user tries to GET /images/image1.png but gets a 404 as it doesn't exist in their tenant. tenant 2 user then POSTs an image to /images/image1.png. tenant 1 user can still GET their original image.
2. appIDs are persistent The tenant 1 user uses their appID and secret key 1 to POST an image to the system at /images/image1.png. secret key 1 gets compromised so it is revoked in the system. secret key 2 is issued to tenant user 1. tenant 1 user uses their appID and secret key 2 to GET the image at /images/image1.png and it succeeds. Any request with secret key 1 fails.