Previously we would use a User Model to get an instance of
a HydroShare Service Client for them. In this effort we're
offloading some of this work to Celery Tasks, which do not
support passing non-serializable Models as parameters. So,
we will be forced to use simple data types.

These mostly follow the create and update paths in the
view with the addition of spawning their own copies of
HydroShare Service, since that cannot be given to them
across the Celery serialization boundary.

Now, in the case of POST we run a Celery job instead of
doing it all within a single request. This sends back a
job_id that can be polled for. This polling will behave
exactly as other such instances.

A HydroShareExportTaskModel is added to poll for results,
set to poll every 6 seconds since this is relatively slow
process. A task model gives us two promises: one for when
the initial request is made, and another for when polling
stops.

We handle errors such as connectivity problems etc in the
start promise failure. We handle response from HydroShare
in the polling promise resolution. The exportToHydroShare
method returns the two promises combined, to resolve when
they are both ready. This isn't currently used, but keeps
the API same as before when we returned the AJAX promise.

Since sending each file takes a few seconds, and when
multiple scenarios are present in a project they have
a large number of files, which can take a lot of time
to send, we increase the timeout of both Celery tasks
for creating and updating resources, as well as front
end that will poll to a corresponding degree.

Since now the HydroShare Export can potentially take
quite a while, during which the user can keep making
changes, with Autosync enabled that would simply add
each change to the queue, leading to sitations where
the app would constantly be exporting to HydroShare.

Furthermore, because this export queue isn't visible
to the user, they can navigate away, blocking export
from completion.

Adding a visible queue that is user-manipulatable is
currently out of scope. Instead, our compromise here
is to disable autosyncing completely, and relying on
the user to export manually when they want.

When we switched to using job uuids for transferring
MapShed results for Subbasin, we didn't update this
HydroShare export functionality which had been broken.

By switching to using the MapShed Job UUID, we enable
GMS file exports to HydroShare again.

Since we no longer autosync projects, and the user must
be prompted to export explicitly, we add a message in the
MultiShare Modal under the HydroShare section saying if
the project has changed since last export.

This message is only visible if the date of last export
is less recent than the latest modified_at date of all
the scenarios in the project. Thus, if any scenario is
modified after an export, this message will be shown.

To allow this, we now always update the client scenario
model with the modified_at date from the server.

Previously we always exported all scenarios for
simplicity. Unfortunately, as we bump up against
the limit of how many files can be exported before
a timeout, especially when the record already exists
and each export checks for a file, deletes it, and
then exports it again, being judicious about which
files we send ensures that we almost never time
out.