Introduce api.Get function to replace api.NewAPIs()[]

[jskelin]

What this PR does / Why we need it:

The api.NewAPIs function shouldn't be used so often as it is. The most obvious problem is the lack of filtration of unreleased endpoints, which leads to inconsistency. Performance optimisation aren't part of this PR.

A possible question is whether the signature of the Get method should contain an error as the last argument, which could indicate that the requested API isn't yet officially supported (under development).

Special notes for your reviewer:

Does this PR introduce a user-facing change?

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[github-actions]

Unit Test Results

1 843 tests  +3   1 843 ✅ +3   28s ⏱️ +2s
  130 suites ±0       0 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit 77145f5. ± Comparison against base commit bbefb1c.

[arthurpitman]

I like the general idea of a api.Get(...) function as it is certainly cleaner than api.NewAPIs()[].

However, is it possible to use this idea more generally, and do we also need a GetAll(...) function or similar to get several APIs? I would want to avoid the situation where we have two ways of doing something.

Also, would it be beneficial to have a uniform error message for asking for API that is not available? In that case, the return types would also change to include an error.

[UnseenWizzard]

I like the idea of this change @jskelin , but I agree with @arthurpitman - we should follow it up with a general change to how APIs are accessed.

In a quick search I found several usages for NewAPIs that should very likely filter out disabled APIs but don't - e.g. the one for CLI auto-completion currently will suggest APIs that are behind a feature flag.

As @arthurpitman suggested, I'd replace the exported NewAPIs (making it a private newAPIs) with a GetAll() and apply the RemoveDisabled filter there. Importantly this still has to return an APIs object, as some code applies further filters that fit it's usecases.

As for returning an error - IMO there is no reason why code using API really needs to differentiate between APIs that are currently filtered out and those that just don't exist. For their purpose, the API just doesn't exist, so IMO the bool is good enough.