Export an object storage interface to allow the backend data mover to ingest data from an application-aware backup tool

[shuguet]

Is your feature request related to a problem? Please describe.
More and more applications and Operators, especially in the cloud native space, seem to come bundled with their own backup tool.
Most of those app-specific backup tools have some kind of capability to backup to an object storage.

While Kanister is able to expose one of its Storage Location Profile to a Blueprint, doing so entirely bypass the datamover being used (for example the recently added support for Kopia).
It also exposes the specifics of the Location Profile (endpoint, credentials, etc.) to the Blueprint.

Describe the solution you'd like
An alternative (or additional) option would be for Kanister to expose an object storage interface to the Blueprint, masquerading as an S3-Compatible endpoint, providing ephemeral credentials, and controlling which resources a Blueprint could access.
That would both simplify writing Blueprints for modern applications with their own app-aware backup capabilities, but also make the process more secure by isolating the Blueprint execution environment from the actual specifics of the underlying destination.
It would also allows the backups generated to be fed through a data mover (Kopia or any other).

Describe alternatives you've considered
Exposing Kanister's Location Profile directly to the Blueprint
Using a ConfigMap+Secret with the Blueprint

In both cases, the app completely bypass the datamover and has to re-implement a lot of the "niceties" provided by Kanister

Environment
Kubernetes Version/Provider: all
Storage Provider: all
Cluster Size (#nodes): N/A
Data Size: N/A

Additional context
None.

[mlavi]

Discussed in today's community meeting; there's a bit more to explore on the use case before justifying and recent engineering priority isn't bringing this forward in the short time frame. Moving to a discussion...