Optionally store the search audio on using Minio with GCS backed

[geohacker]

To enabled https://github.com/developmentseed/bioacoustics-frontend/issues/125, the API should have a method to store the search audio in a storage account. Ideally we can make this an optional feature so if there are concerns of collecting data from the user we can spin a stack without it (can just not configure the GCS ENV or something)

@willemarcel could we add an /upload endpoint using Minio client for storing the audio file on GCS? The endpoint should return the URL of the file so the frontend can add it to the query param in the browser.

cc @oliverroick @sunu

[oliverroick]

If this feature is optional in then we need to handle this in the front-end. It basically means, if the backend doesn't support uploads then we can't offer the permalink feature because we wouldn't be able to retrieve the audio. It's possible to do but it sounds like a can of worms.

[geohacker]

@oliverroick Yeah I agree this is not super straightforward but I think we will have to do it for reasons in case Google/a2o/users don't want to make audio public or integrate a storage backend.

[geohacker]

@willemarcel I caught up with @oliverroick to discuss this a bit more and he suggested that we add a /capabilities endpoint. With that the frontend should be able to figure out if audio storage is enabled. Does that sound ok to you? To summarise, we'll need two endpoints:

1. GET /capabilities — which for now just returns {public_storage: true/false}
2. POST /upload — which takes the audio file and then returns a URL

I think capabilities is a good idea and we can later on add things like last time index was updated etc.