Update handling of info.json requests

[donaldgray]

As detailed in Cantaloupe Image-Server RFC we can leverage Cantaloupes ability to fulfil info.json requests.

To date these requests were generated from a template and as such very quick to return.

We still want to handle info.json requests via Orchestrator so investigate best way to do this. Cantaloupe has logic for returning optimal tile sizes so we want to take advantage of this.

Decide:

• What would be need to store? e.g. tile sizes only? Fully generated info.json?
  • Full info.json should be recorded
• Where do we store it?
  • not solely in memory, somewhere more permanent. Possibly S3 and just rewrite requests out?
• When do we generate/store it? (on first request? at ingestion time?)
  • On first request, if it exists return it else generate, store + return.

[donaldgray]

Possible duplicate of #238 and #256

[donaldgray]

When info.json is requested the flow is (s3 key contains version, different versions will have different keys):

• Does this exist in s3? If so read from S3, update "id"/"@id" and return. Else,
• Does the image-server support requested version? If not abort. Else,
• Get info.json from image-server. Add authServices (if required).
• Save updated info.json to S3.
• Hand back to calling request - will update "id"/"@id" and return

The "id"/"@id" property is updated each time it is returned because we want to avoid needing to save multiple different versions in S3 with specific Ids. The Id can differ if:

• Canonical image-version is changed
• Requested via a different hostname (E.g. behind CloudFront).