Expose funcs to allow for subcommand decomposition

[dfreilich]

Signed-off-by: David Freilich dfreilich@vmware.com

Summary

A number of the funcs in the commands package are private, which creates issues when trying to decompose the package into subcommands, as part of #597. This exposes a number of funcs, to ensure that further PRs (such as #959 and #962) will be easier to merge in.

Documentation

• Should this change be documented?
  • No

Related

[codecov]

Codecov Report

Merging #964 (fb2e983) into main (f85ce47) will decrease coverage by 0.01%.
The diff coverage is 98.08%.

@@            Coverage Diff             @@
##             main     #964      +/-   ##
==========================================
- Coverage   77.67%   77.67%   -0.00%     
==========================================
  Files         103      103              
  Lines        5006     5009       +3     
==========================================
+ Hits         3888     3890       +2     
- Misses        724      725       +1     
  Partials      394      394              

Flag	Coverage Δ
os_linux	77.67% <98.08%> (-<0.01%)	⬇️
os_macos	74.65% <98.08%> (-<0.01%)	⬇️
os_windows	100.00% <ø> (?)
unit	77.67% <98.08%> (-<0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

[dfreilich]

@jromero This PR (and the connected ones) depend on the resolution of your comment here: #959 (comment)

What's the value or reasoning for stack to be its own package outside of commands? It smells like an anti-pattern but maybe I'm missing something.

Personally, I feel like it's useful for the related commands to be in their own directory. It makes the command structure a bit cleaner, in my eyes, though I do recognize that in general, go practices are ok with large flat structures.