refactor: Abstracted the different config validation routes

[JulesFaucherre]

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have checked for similar issues and haven't found anything relevant.
• This is not a security issue (which should be reported here: https://circleci.com/security/)
• I have read Contribution Guidelines.

Changes

Abstracted the API that compiles config so that it's transparent whether you use the new API route or the GraphQL endpoint

Rationale

The config compilation has recently been moved from the GraphQL to a new API route. At first it was implemented such as if the compilation request failed with a 404, we tried falling back to the legacy GraphQL endpoint because it mostly meant that we were on old Server version that did not have the new API route
Now you have to pass an APIClient to the config compiler upon creation. This client should be obtained with config.NewWithConfig(*settings.Config). This API client is an interface which implementation either request the new API route or the GraphQL
To detect which implementation must be given, a call is made to the new route, on 404 the GraphQL implementation is returned, else the new API route implementation is returned

Screenshots

Nothing to show as it only changes how the code operates internally but do not add any product change

[loderunner]

Very readable code, for a non-trivial problem. Well done! 👏

Minor comments, none should be blocking. I'll let you decide what you want to do with them and resolve the conversations as needed.

[loderunner]

Should we be returning an error from reading the response body along with the status code? It seems a little strange.

For example, we could have the server respond with a 200 OK, but for some reason, fail to read the body of the response. We'd then return 200 with an error message, unrelated to the HTTP protocol.

The way I see it, we should either return:

• 2xx HTTP status code - no error
• 4xx-5xx HTTP status code - HTTP error (from body or from status text)
• HTTP status code zero value - non-HTTP error

[loderunner]

This one doesn't seem to change. Can we make this a const?

Suggested change

	var (
	compilePath = "compile-config-with-defaults"
	)
	const compilePath = "compile-config-with-defaults"

[loderunner]

I think the internals of this function could be explained. In a year's time, it's probable that another developer will face this and wonder why v1 results in a 404. 🙃

Do you think a comment would be justified here?

[JulesFaucherre]

Agree! Thanks