OMERO authentication for microservice

[mtbc]

The Zarr HTTP microservice could enforce OMERO permissions. A simple but effective version might have the microservice provide its pixels service a ReaderSecurityCheck validating, say, a short token for either an image or fileset ID, comprising, say,

• hash of sorted used files (empty for non-FS images) (to guard against 2019-SV1)
• session ID from a read-write server login (determines token expiration)
• hash of the above composed with session UUID.

Better for the longer term might be to hand the microservice a "give access to these image IDs until this time" message that JCA somehow checks via Signature.verify.

Also investigate any interaction with @manics' work on S3 access tokens.

[manics]

It's best to treat the S3 access tokens as a decoupled backend microservice e.g. s3-ms-tokenservice that has no knowledge of OMERO. It's included in this repo for now to avoid creating another repo. The client of that microservice is responsible for deciding whether to allow a user access to an S3 path:

1. User requests a Zarr from omero-ms-zarr for an image
2. omero-ms-zarr checks whether the user is authorised to read the image
3. omero-ms-zarr does whatever it needs to do to determine whether to generate a zarr on the fly or give access to a zarr on S3
4. If it decides to give the user access to s3 it requests a token from s3-ms-tokenservice for a particular path or path prefix
5. s3-ms-tokenservice returns a time-limited token to omero-ms-zarr which passes it back to the user along with the S3 URL
6. User uses the S3 token and URL to read the Zarr using the S3 API.