Add special case operation names

[dshebib]

Adds a few more operations to the api documentation in the appropriate locations.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dshebib
Once this PR has been reviewed and has the lgtm label, please assign feloy for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tengqm]

Please verify whether these operations are properly supported and thus should not be excluded.

[dshebib]

getCodeVersion: This seems to get the Kubernetes code version as intended
logFileHandle, logFileListHandler: Good catch, these are not supported

[dshebib]

Should note that this PR will cause the generator to emit a few lines that are formatted as errors. @tengqm I am not familiar with the CI tools in this repo, should I reformat them as standard logs to avoid causing issues? The lines are the following:

�[31mNo Definition found for getCodeVersion [/version/].�[0m
�[31mNo Definition found for getServiceAccountIssuerOpenIDKeyset [/openid/v1/jwks/].�[0m
�[31mNo Definition found for getServiceAccountIssuerOpenIDConfiguration [/.well-known/openid-configuration/].�[0m
�[31mNo Definition found for createCoreV1NamespacedPodBinding [/api/v1/namespaces/{namespace}/pods/{name}/binding].�[0m

Emitted because though these operations have definitions, the generator does not associate them with a resource. The generated html after running the generator does not omit any pre-existing information and only moves information from the new Operations section to their respective sections (/pod/ etc.)

[tengqm]

@dshebib The operations appear in the log because we don't have special logics to handle them.
In other words, our pattern matching logic cannot identify them as valid operations, and, that is the reason we temporarily excluded them from the reference docs generated.

For each operation from the swagger spec, we should either properly generate reference for that operator, or we should report it as an exception. We are not supposed to fail silently. This is the reason I asked you to double check this PR.

[dshebib]

Sorry, I should have clarified. The documentation gets correctly generated according to the definition for the operation itself in the swagger.json. The error is generated because there is no associated resource definition. Therefore, the final behaviour is that documentation is generated for the endpoint in a miscellaneous 'operations' section:

[dshebib]

In checking this, I found that the logic from my previous PR does not respect and exclude the excluded operations in the config from the miscellaneous operations section. I will fix this this weekend.