Added support for Presentation 3 services property

[stephenwf]

trafficstars

1. Adds check for resources with id in addition to @id to find services from parent resources
2. Adds services to pool of services to check when listing all services.
3. Always looks for references to services in parent resources - this might be problematic
4. Fixes previously passing test where a level1 image service was requested but only level0 was available. Test reflects ground truth but unsure if functionality relied on this bug.

For 3. an alternative to always checking would be to determine that the service doesn't have enough data:

{
  "id": "https://api.bl.uk/auth/iiif/login",
  "type": "AuthCookieService1"
}

Which references this in the manifest.services block:

{
  "id": "https://api.bl.uk/auth/iiif/login",
  "type": "AuthCookieService1",
  "profile": "http://iiif.io/api/auth/1/login",
  "description": {
    "en": [
      "Some portions of this recording may be unavailable due to rights restrictions."
    ]
  },
  "header": {
    "en": [
      "Please Log-In"
    ]
  },
  "label": {
    "en": [
      "Login to The British Library"
    ]
  },
  "service": [
    {
      "id": "https://api.bl.uk/auth/iiif/token",
      "type": "AuthTokenService1",
      "profile": "http://iiif.io/api/auth/1/token"
    }
  ]
}

The lack of profile might be enough? It's possible that in misconfigured manifests this would cause issues, if you had 2 services with the same identifier when you looked for the service recursively in the JSON-LD it would always resolve the first. Even if that service had a different structure.

I believe this is correct behaviour though, short of merging all services we find. cc @tomcrane

[tomcrane]

Always looks for references to services in parent resources - this might be problematic

Only allowed on top level - manifest and collection - does that make it simpler?

Here's a useful example: https://iiif.wellcomecollection.org/presentation/b18323017

(WIP, might not be stable there)

[stephenwf]

Hmm, I wonder why the Utils.traverseAndFind was used before? Are there cases where a canvas needs to find a service that's not only inside the manifest?

cc @edsilv

[tomcrane]

The services formalises something the UV was doing anyway - mainly to avoid JSON bloat by repeating the same auth block 500 times on a 500-page manifest. It allowed the service to be declared once anywhere (typically on first occurrence) but then not repeat the full service. This is valid JSON-LD but an optimisation that only the UV might have seen. the services block gives you a peg to hang that sort of service on, so it's more conventional.

So the UV should probably keep the traverse, but people should use this special known location in P3 manifests to do this.

[tomcrane]

Another test fixture: https://iiif.wellcomecollection.org/presentation/b19192162 (clickthrough, declared once in full in services, thereafter as

"service": {
   "@id": "https://iiif.wellcomecollection.org/auth/clickthrough",
   "@type": "AuthCookieService1"
}