feat: make InitDefaultCompletionCmd public

[gssbzn]

closes #1464

I also took the liberty to directly call it when generating docs as it seems that was already the case for InitDefaultHelpCmd

[CLAassistant]

All committers have signed the CLA.

[marckhouzam]

Although I am not familiar with the details of the documentation generation code, this change does seem appropriate, and all the existing tests keep passing.

[github-actions]

This PR is being marked as stale due to a long period of inactivity

[gssbzn]

Random comment to make the bot not close this PR

[jpmcb]

Hmmm I want to take a second to think about this one quick before merging.

We'd be changing the completions API to include a new Init that was once private but not changing the existing API that would constitute a breaking change?

[gssbzn]

but not changing the existing API that would constitute a breaking change?

Right now calling cmd.InitDefaultCompletionCmd() inside the different Gen commands could be seen as a breaking change I could give you that, I'm happy to rollback that change if that gets this merged, at least having InitDefaultCompletionCmd public would reduce a lot of the hacking we have in place to be able to generate docs for the auto complete commands

[jpmcb]

This all looks good to me, but I think just for stability, this needs to wait for a 2.0 release. Since technically the API change would be a breaking change. If there's one thing I hate, it's surprising users with unexpected breaking changes 😂

Otherwise, I think this implementation makes perfect sense.

[marckhouzam]

We'd be changing the completions API to include a new Init that was once private but not changing the existing API that would constitute a breaking change?

I'm not understanding well. Adding a new public function does not break the API, does it? We've added a bunch of public functions and constants when we added Go shell completions...

[github-actions]

This PR is being marked as stale due to a long period of inactivity

[johnSchnake]

The exported method itself shouldn't be breaking unless I'm misunderstanding something. @jpmcb if he removes the addition to the method and just exports the method, is this good to merge?

[gssbzn]

@marckhouzam @jpmcb I've removed the calls to document the completion command from the default docs in the hope that this change makes it for the spring release, let me know if there's something else of concern here

[jpmcb]

I'm not understanding well. Adding a new public function does not break the API, does it? We've added a bunch of public functions and constants when we added Go shell completions...

You're right - I was being overly cautious; thanks for the feedback all

[jpmcb]

If possible, and if @gssbzn has the bandwidth, I'd like to see a bit of documentation around this now that we'll be making it a public method. Otherwise, we can address that in subsequent PRs

[gssbzn]

@jpmcb what kind of documentation were you looking for? when to use? would documenting in the different *.md files for /doc enough?