feat: adds an upload artifacts command to konvoy image builder

[faiq]

What problem does this PR solve?:
Creates an upload artifacts command to upload artifacts to hosts specified in an inventory file.

Which issue(s) does this PR fix?:

https://jira.d2iq.com/browse/D2IQ-83933

Special notes for your reviewer:

I ran the command like so:

$ bin/konvoy-image-wrapper upload artifacts --inventory-file=ansible-inventory.yaml --container-images-dir=./artifacts/image-bundles/ --os-packages-bundle=./artifacts/os-packages_1.21.6_x86_64_rpms.tar.gz --pip-packages-bundle=./artifacts/pip-packages.tar.gz 

I used previous existing terraform scripts to bring up centos7 hosts.

Does this PR introduce a user-facing change?:

feat: adds a upload artifacts command for hosts that will be used in offline mode.

[github-actions]

File	Coverage
All files	3%	❌
pkg/ansible/runner.go	0%	❌
pkg/app/artifacts.go	0%	❌
pkg/app/build.go	7%	❌
pkg/app/errors.go	0%	❌
pkg/app/provision.go	0%	❌
pkg/app/root.go	0%	❌
pkg/app/validate.go	0%	❌
pkg/appansible/io.go	0%	❌
pkg/appansible/playbook.go	0%	❌
pkg/logging/logger.go	0%	❌
pkg/packer/manifest.go	0%	❌
pkg/packer/packer.go	0%	❌
pkg/stringutil/rand.go	0%	❌
pkg/version/info.go	0%	❌

Minimum allowed coverage is 75%

Generated by 🐒 cobertura-action against 27cd289

[supershal]

Please add related target in Makefile. I think the e2e.*.offline targets will change to support this.

[supershal]

for next iteration: Should we think about combining all artifacts into a single versioned tar if we need to provide all three type of artifacts (rpms, pip packages, images) all the time? This could prevent version mismatching between rpms and images artifacts. also it would be easier for users to manage/download one single tar file. Then this command could become simple where it could upload/sync sort of anything (for ex. Helm charts) to each host/bastion in the inventory.

Edit: Need to take care of OS specific artifacts Vs OS independent artifacts

[supershal]

we should add shorthands notations to all commands. wdyt?

[faiq]

These should probably be addressed in a refactor for all of the subcommands.

[supershal]

sounds good.

[supershal]

if we are following kubectl conventions, it would be good to follow those when we refactoring flags.
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-cli/kubectl-conventions.md#flag-conventions

[faiq]

We should actually keep this here. In the case where the user is trying to build an AMI with the offline bundles present

[supershal]

this is going to be a very useful feature.