Replace LORIS with IIP, remove caching

[qjhart]

The LORIS image works as the IIIF image service for the DAMS. We use IIIF as the standard method for on-the-fly image processing for the DAMS. LORIS gets it's speed primarily by caching images, which works well for the statically defined IIIF URLs in the system. The problem is that loris has no convenient administration interface, and stale caches are difficult to remediate.

We could remove loris completely and replace with the IIP server and premade web-ready multi-resolution tiled files. This would be performed with two components. The IIP component would work directly on the fcrepo OCFL file system. Hopefully, this would allow for a very simple configuration of the IIP server. The OCFL volume would be mounted read-only onto the IIP server container. The IIP endpoint would be internal only.

The second component would be the mapping of the LDP service request to the equivalent IIP service request. This would require converting the LDP URL to it's OCFL filename. It would be great if this was possible with a fcrepo derived function, but can also be developed either using an existing javascript OCFL library, or creating that function directly.

Finally, we would need to create our tiled files for the images we wanted available via the service. I have read in some papers that the kakadu JP2k is the best format, but in that case we would have to deal with a commercial library, and the difficulty in using our other tools for this. Instead, using multi-resolution tiffs, with JPEG compression seems like the best option.

Similar to our current clientMedia strategy, binary image metadata would have a pointer to an equivalent tiled file. We would need to consider mapping IIF requests on the native images to their tiled counterparts. This would allow the front-ends to work with and without a tiled replicate

[qjhart]

@jrmerz can you review this general idea, and we can start planning a test.