[content-service-api] add new snapshot initializer

[sagor999]

Description

This just adds a new from snapshot volume initializer that is used by #9475 to add support for initializing workspace from snapshot volume.

Related Issue(s)

Part of #9475

How to test

Release Notes

none 

Documentation

[jenting]

The rest LGTM

[jenting]

/werft run

👍 started the job as gitpod-build-pavel-snapshot-init.2
(with .werft/ from main)

[csweichel]

How would this be used? I.e. who would decide how when to use this initializer? Server can hardly make that decision, because workspace content storage is opaque to webapp.

IMHO we should try and stick to the backup/prebuild/snapshot initializer we have today which rely on a "snapshot URL" (or in case of the backup initializer use their own convention to discover the backup).

[sagor999]

/werft run with-clean-slate-deployment

👍 started the job as gitpod-build-pavel-snapshot-init.3
(with .werft/ from main)

[geropl]

How would this be used? I.e. who would decide how when to use this initializer? Server can hardly make that decision, because workspace content storage is opaque to webapp.

IMHO we should try and stick to the backup/prebuild/snapshot initializer we have today which rely on a "snapshot URL" (or in case of the backup initializer use their own convention to discover the backup).

@sagor999 Would be interested in this as well ☝️ So far I'm not aware WebApp is going to store information about how workspace content is stored; that was handled inside content-service. Is that going to change in any of the following PRs? Or is this a workspace-internal change, and just happens to expand the API surface? 🤔

[sagor999]

@csweichel this is used by #9475, if you want to see how decision is being made when to use it.
It will be very cumbersome (I think) to add this into existing initializer (and possibly confusing)

[sagor999]

@csweichel @geropl I extracted this from original PR at #9475 to make it easier to review those changes piece by piece, but I guess this was not very helpful. You can look at that PR to see how this initializer is used.

[sagor999]

@csweichel @geropl just to add, if there is a concern that there are too many initializers, once PVC approach is adopted, FromBackup and Snapshot initializers will be removed, as they will be obsolete.

[csweichel]

@sagor999 I've put a call in for tomorrow - I reckon we should catch up and go through those changes sync.

[sagor999]

After a sync with @csweichel decided it will be best to re-use existing initializers so that it is easier to add PVC support into prebuilds later on.