Support uploading model runs from the web client

[floryst]

Add support for uploading model runs from the web client.

This draft PR gets the end-to-end pipeline of uploading and processing a zip file of geojsons. There are a couple of extra things to do to complete this PR.

• Cleanup the UI
• Enforce certain validations on the UI (e.g. not allowed to submit without a title)
• Send the private flag, and apply the private flag on the backend
• Run code linter
• Address the TODOs

The core pipeline can use an initial review pass.

Screenshots:

[floryst]

@BryonLewis is there an existing notion of a private/public model run in RD-WATCH?

Bryon: No there isn't. I've added fields to the Region and model-run endpoints to indicate if a item is public (it defaults to true). I haven't done any filtering or sorting on those fields yet (except maybe custom regions).

[BryonLewis]

I haven't tested yet, just looked at the code and added a few suggestions.

[BryonLewis]

After going through the animation export I think we should probably move some of these into their own file. In the future we should break up the __init__.py at least into an image downloading file (there are a lot of functions that handle that.).

[floryst]

Recent updates:

• use django-s3-file-field with s3 in prod, minio in dev
• properly type the VFileInput model value
• skip originator validation in SiteFeature. This is necessary because ingested geojsons may have originators that are not yet in the database. We can safely skip this check because we will add the missing performers later before saving the model run.
  • side note: the implementation would be better with pydantic v2 contexts
• refresh the performers and regions when a successful upload occurs

[BryonLewis]

Sorry I've been a bit busy on other projects but got around to review this. Some of the comments are generic things that could be implemented in the future. The main things are:

• The Region override not working properly
• I think it would be good to get the modelrun list to refresh on upload task completion.

The section about allowing multiple uploads to be processed at once and having the dialog be non-blocking isn't as important now considering modelruns should be processed in a few seconds.

[BryonLewis]

In regards to this being persistent.

Not a huge issue because I know the infrastructure to properly handle it would be annoying. I'm wondering if something that is dependent on a celery worker being in an available state and running the task should block access to the rest of the application while it's processing.

When I'm talking about infrastructure I mean that if we have userId tied to the upload and the task we could add another endpoint in the views model_run for listing all currently active upload tasks for a user. The user could then see the progress of those tasks. To know they are currently doing something. This gives the extra benefit of not needing to block user input on fields while an upload is processing. Allowing for a user to upload a zip file and while it is processing upload another zip file with no delay. These are just thoughts right now and probably don't need to be implemented for this PR.

[floryst]

This PR now depends on #502 and #503.

[BryonLewis]

Tested on a full unique zip with custom regions and size and it worked perfectly. Even the overrides worked well.