This PR adds a graphql handler to the catalogd server (behind a feature gate). In order to add the graphql handler, I decided to refactor the storage and http handlers to decouple the storage and serving aspects into separate packages.

The idea with the GraphQL storage is that when we store an FBC, we build up a graphql schema dynamically based on the content of the FBC. The GraphQL handler the uses the stored (in memory) schemas for each catalog and serves a GraphQL API for them. The result being that catalogd is still a "dumb pipe" for FBC data. The GraphQL API is directly derived from the FBC API (or at least the parts of the FBC API that are in use somewhere in the served FBC).

To play with it, I've enabled the GraphQL explorer handler, so you can:

make run-experimental
kubectl port-forward -n olmv1-system service/catalogd-service 8443:443

And then open https://localhost:8443/catalogs/operatorhubio/api/v1/graphql

And here's are some interesting queries to run:

Bundle search metadata

{
  olmBundle {
    package
    name
    properties(type: "olm.csv.metadata") {
      value(jq:".annotations | [to_entries[] | select(.key | test(\"features|valid-subscription|description|capabilities|categories\"))] | from_entries")
    }
  }
}

What OLMv1 operator-controller actually needs for resolution:

{
  olmChannel {
    package
    name
    entries {
      name
      replaces
      skips
      skipRange
    }
  }
  olmBundle {
    package
    name
    image
  }
}

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)