Forward compatibility (HATEOAS) - Discover all endpoints dynamically from `api` response

[devraj]

According to the documentation we should not reference /api/items and some other endpoints statically, this should instead be discovered from the features.items.items.href attribute of the /api response.

To find an item, pass a substring of its name to the link at features.items.items.href in the results of a call to /api. If you are sure of its name, place the name inside " quotes, and it will use a full string match. Both types of search are case-insensitive.

This ticket is to refactor the current implementation to add discovery.

As the Gallagher documentation states this is for HATEOAS compatibility:

This is a self-referencing REST API that follows the principles of HATEOAS. Other than the initial GET to /api when it first connects, your source code should not contain any URLs, as they are subject to change. You should append the query parameters this document describes for operations such as filtering and searching, but everying in the path should come from the results of /api or pages linked from it.

/api only shows licensed API calls.

Be prepared to append query parameters to URLs that already have their own: do not assume that you can simply add a question mark and your parameters.

[devraj]

Further to this, the /api endpoint returns href for the features that have been licensed by the client and omits a href for ones that aren't. Our pyndatic models have each one of these set to an Optional.

All features should use this discovery result to configure itself dynamically.