feat: Add server that provides k-apps contents

[mikolajb]

What problem does this PR solve?:
Produce a docker image with http server.

Which issue(s) does this PR fix?:
https://jira.nutanix.com/browse/NCN-102822

Special notes for your reviewer:
To move things quickly, I'm using github.com/sigoden/dufs. I use it because it supports tls but I'm planning to create our own (maybe a few lines in Python - let's see what's the fastest).

Does this PR introduce a user-facing change?:

Checklist

• If the PR adds a version bump, ensure there is no breaking change in Licensing model (or NA).
• If a chart is changed or app configuration is significantly changed, the chart version is correctly incremented (so that apps are not automatically upgraded from a previous version of DKP).

[takirala]

Will this server be a thing in 2.14 (or if/when we have OCI support) ? If not, wdyt of using just a simple container image that has the necessary artifacts at a certain known path. pulling it as init container will be enough. I am not against the idea of server but this seems like an overkill for a soon to be dead code (and for something that is very short lived - bootstrap job takes less than 10m in happy path).

[mikolajb]

Will this server be a thing in 2.14 (or if/when we have OCI support) ? If not, wdyt of using just a simple container image that has the necessary artifacts at a certain known path. pulling it as init container will be enough. I am not against the idea of server but this seems like an overkill for a soon to be dead code (and for something that is very short lived - bootstrap job takes less than 10m in happy path).

Yes, I get it, the choice is between having a server and relying on a git operator way of initializing the repository (that won't change when we move to OCI) or having an init container and creating a custom way of initializing the repository that will go away when we move to the OCI. I would favor the former.

In other words, this web server fits in the APIs and git operator not the other way around.

[takirala]

So in the current way, we would have to:

• refactor kapps tooling to publish oci image in 2.14
• refactor bootstrap job to consume oci repo (instead of fetching from http server)

But, if we can publish a docker image (that is very close a future oci image, basically a simple image that has some file system) then we can keep the future refactoring minimal by

• refactoring kapps by pushing the oci image instead of the plain docker image (this refactor ll be much more minimal compared to whats being done in this PR)
• refactoring bootstrap job to get the content using https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/ in 2.14 or getting the same contents from .status.artifact.url of OCIRepository which will again be a signifcantly smaller refactor compared to moving away from hitting an http endpoint.

[coveralls]

Pull Request Test Coverage Report for Build 11167419015

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 51.557%

---

Totals
Change from base Build 11163988221:	0.0%
Covered Lines:	149
Relevant Lines:	289

---

💛 - Coveralls

[mikolajb]

So in the current way, we would have to:

• refactor kapps tooling to publish oci image in 2.14
• refactor bootstrap job to consume oci repo (instead of fetching from http server)

We discussed it on Slack but for someone reading it: both are already happening actually. The oci artifact is already being published since 2.12. Git operator is being able to consume OCI artifact when initializing a repository.

In other words: this method is reducing the future refactoring to the absolute minimum.