Clarify the response code when platform does not provide the required api version header

[waterlink]

What is the problem this PR solves? fixes #673

Checklist:

• [x] The swagger.yaml doc has been updated with any required changes (n/a)
• [x] The openapi.yaml doc has been updated with any required changes (n/a)

[cfdreddbot]

:white_check_mark: Hey waterlink! The commit authors and yourself have already signed the CLA.

[mattmcneeney]

Two more needed @fmui @jberkhahn

[bulataleev]

@waterlink Thank you for fixing the issue, however I think that the idea in "the Service Broker MAY reject the request with 400 Bad Request" may cause ambiguous behaviour that the user expects from the request in case of incorrect or malformated data. Please consider "the Service Broker SHOULD reject the request with 400 Bad Request". Would be happy to answer questions related with my suggestion

[waterlink]

@bulataleev

The issue is that the service broker doesn't have to check this pre-condition in the first place (for example, if it it doesn't rely on any advanced features, it can just ignore the pre-condition entirely):

This header allows Service Brokers to reject requests from Platforms for versions they do not support. While minor API revisions will always be additive, it is possible that Service Brokers depend on a feature from a newer version of the API that is supported by the Platform. In this scenario the Service Broker MAY reject the request with 412 Precondition Failed and provide a message that informs the operator of the API version that is to be used instead.

It would be strange for brokers, that didn’t ever had to look at this header (because of the above MAY), suddenly have to verify that the header is present (because of a SHOULD).

That’s why I’ve extrapolated the same MAY behaviour.

[aaukhatov]

@waterlink Thank you!