Fully Deprecate internal chartmuseum deployment

[michaeljguarino]

Use Case

The plural api currently proxies and partially implements the chartmuseum protocol to handle chart storage, with some operations like storage and retrieval done with an internal instance of chartmuseum. It's not clear this is even necessary and we could simplify+save a bit of space by eliminating this chartmuseum layer and just uploading/retrieving from s3 directly.

Ideas of Implementation

Use ExAws' s3 uploader in the upload chart endpoint (instead of proxying to chartmuseum get) and proxy against a signed url for the chart GET endpoint

Additional Info

We should probably test this during a weekend and be prepared to rollback (version the server appropriately when deploying)

---

Message from the maintainers:

Excited about this feature? Give it a 👍. We factor engagement into prioritization.

[davidspek]

With the release process now implemented it should be easier to test this and roll back if needed.

[davidspek]

Rather than using chartmuseum it might also be an option to use OCI instead going forward so the registry can be used for both containers and charts.