Manifest v2 support

[itowlson]

For when spinframework/spin#1780 lands. The new load path moves all of the LockedApp fiddliness into the Spin loader, so we pretty much don't have to do anything to consume it any more!

The Spin crate references will need to be set back to the Fermyon repo at this point - this points them at @lann's branch just for development.

[itowlson]

This seems to be having a problem with the Spin assets-test test case. The app deploys but never goes ready, and Cloud just says "failed to prepare your Spin application." Other apps with zero-length files work fine. Investigating!

[lann]

Might have a logical conflict with @vdice's OCI changes; it's an old branch!

[itowlson]

The problem happens when a (v1, haven't tested with v2 yet) manifest omits the application HTTP base. The "failed to prepare" may be spurious, although earlier it was showing the domain as having a problem. For now I'll work on the basis that this is a client problem with the readiness detection.

[itowlson]

Something amiss with the digest computation.

When it has base, the digest is 335de18dadb8ac201ef8e4a6252600948166d3bde7493de2abc4ac7b06e618bc

When it doesn't have base, the cloud plugin looks for digest 125f0c859c1a8b8ef8afd97ff1dcfaa24e400c5e6c8f736e239dcf177ffd6e31 but the cloud reports digest 335de18dadb8ac201ef8e4a6252600948166d3bde7493de2abc4ac7b06e618bc.

The digest is coming from within the spin_oci push_locked method. Next step is to try a spin registry push and see if the digest lines up with what the registry calculates.

[itowlson]

spin registry push (to ghcr) comes up with the same value whether it has base or not.

[itowlson]

Correction. spin registry push does come up with different digests depending on whether or not base was present, and these match the digests that the cloud plugin looks for.

[lann]

We should probably rethink how we track readiness. Cloud already assigns a unique ID to each deployment; we should be able to expose it in the .well-known info and check that instead.

[itowlson]

Sure. That might need a Cloud API update - looking at the Swagger it seems like the only place the deployment ID is currently returned is in logs, though I could well be missing something! @bacongobbler is the deployment ID available during the deployment cycle itself?

[bacongobbler]

Yes, it should be. Cloud assigns a unique ID to each deployment and passes that ID to the runtime.

[itowlson]

The diagnosis of OCI digest weirdness was wrong. Baseless applications don't come ready at all - the supposed digest issue was down to the old application still being live.

[itowlson]

I think this is good to go. Thank you @lann for the HTTP base fix!

[lann]

I guess @itowlson has reviewed my contribution here so its fine for me to review his...