Restrict use of availability check to prevent misuse

[nickevansuk]

The availability check is designed to be used at the start of the booking process, rather than triggered during page browsing (e.g. a user browsing the session page on a third party site), so as not to create additional load on booking system servers.

A crucial point here: both RPDE and the Open Booking API are intended to minimise load on the booking system servers, with the latter producing load which is proportional to the number of bookings (and therefore revenue) NOT proportional to the number of searches.

The Opportunity API makes no such promises, as it will allow computationally expensive queries to be constructed which result in no additional revenue, and could be used to facilitate search and discovery use cases which generate high API traffic volumes.

If booking systems are happy to provide access to the Opportunity API to key partners, they should do so separately to the Open Booking API, as such Opportunity API partners would need to be performing caching etc appropriately for search & discovery, and may require rate limiting.

The availability check should be moved into the Opportunity API for this reason, so that access can be controlled separately. This together with a move towards quotes for the Open Booking API would discourage developers from using parts of the Open Booking API as a replacement for the open feed.

[nickevansuk]

C1, C2 and B in the current specification completely solve this - as C1 is used for the first step of the checkout (and as an availability check) but does not lend itself to accidental abuse the way that a "get availability" endpoint does - chiefly because such an abusing implementation would need to generate UUIDs for each request!