feature/copy-to-local-cache-request

[BrianWhitneyAI]

Description

The purpose of this PR is to add in the functionality for submitting the cache request and resolve #291. This PR does three main things:

1. Repurposes the FileDownloadServiceBaseURl which was unused to AicsLoadBalancerBaseURl
2. Adds cacheFiles to the existing logic to build the request.
3. Adds a rawPut function to the existing HttpServiceBase for put functionality.

Request Format

        var url = "http://stg-aics/fss2/v3.0/file/cache";
        var id = "03c3eaf8236b4fa4bb1bba14dad12a02";
        var params = {
            "fileIds": [id]
        };
        var xmlHttp = new XMLHttpRequest();
        xmlHttp.open("PUT", url);
        xmlHttp.setRequestHeader("X-User-Id", "daniel.saelid");
        xmlHttp.setRequestHeader("Content-Type", "application/json")
        xmlHttp.send(JSON.stringify(params));

Testing

This pr has been tested against staging, but has not been tested against production as it is blocked by CORS policy.

[BrianWhitneyAI]

This may be for another PR but we need to make some decisions about attaching user ids to these requests. We have existing functionality to access the users credentials on desktop but not on web.

[BrianWhitneyAI]

This also doesn't contain any notification content to the user about success/failure (apart from invalid submissions) and the response is unused. We need to think about what we want to return to users.

[BrianWhitneyAI]

This may be for another PR but we need to make some decisions about attaching user ids to these requests. We have existing functionality to access the users credentials on desktop but not on web.

In 46bae5d we use the existing username to build the request. This only works for desktop so we disabled the option for web in f61ded5

[saeliddp]

This also doesn't contain any notification content to the user about success/failure (apart from invalid submissions) and the response is unused. We need to think about what we want to return to users.

As of right now, there are 5 possible statuses for each of the files submitted in the request--I'll give suggestions for what to immediately show users based on each

• DOWNLOAD_STARTED - spinning progress wheel
• DOWNLOAD_IN_PROGRESS - spinning progress wheel
• DOWNLOAD_COMPLETE - green check mark indicating cached file
• FILE_RECORD_NOT_FOUND - red 'x' indicating failure
• FILE_NOT_FOUND_ON_CLOUD - red 'x' indicating failure

For files that haven't been recently sent to the cache endpoint, state can be inferred from the following field combinations:

• shouldBeInLocal=true, localPath=null - spinning progress wheel (caching in progress)
• shouldBeInLocal=true, localPath=<something> - green check mark (file is in cache)
• shouldBeInLocal=false - some UI element to show that the file is not cached

Note: the fields I just described above haven't yet been implemented in the ETL, I'm working on that now. The status response from the cache endpoint is good to go though.