feat(cas-backend): introduce fallback mechanism

[Piskoo]

Adds support for configuring a fallback CAS backend that is automatically used when the default backend becomes unavailable.

Changes

• Added fallback boolean field to CAS backends
• A backend cannot be both default and fallback
• Creating a new fallback backend automatically unsets the previous one
• Fallback backends are included in periodic validation (every 30 minutes)
• During attestation process cas backend is decided as follows:
  • Try default backend
  • If default invalid, try fallback backend
  • If fallback invalid or missing, return error
• Added --fallback flag to all casbackend add commands.

Example

$ chainloop casbackend add oci --repo index.docker.io/repo --username name --password password  --name fallbacktest --fallback

┌───────────────┬────────────────────────┬──────────┬─────────────┬───────────────┬─────────┬──────────┬────────┐
│ NAME          │ LOCATION               │ PROVIDER │ DESCRIPTION │ LIMITS        │ DEFAULT │ FALLBACK │ STATUS │
├───────────────┼────────────────────────┼──────────┼─────────────┼───────────────┼─────────┼──────────┼────────┤
│ fallbacktest  │ index.docker.io/repo   │ OCI      │             │ MaxSize: 300M │ false   │ true     │ valid  │
└───────────────┴────────────────────────┴──────────┴─────────────┴───────────────┴─────────┴──────────┴────────┘

During attestation init cas backend is decided seamlessly, we will provide information on what cas backend was used in the attestation itself.

[migmartri]

can defaultBackend be nil?

[migmartri]

we might be able to use something called handle_errors?

[migmartri]

this error message is not accurate, let's try to use handle_errors

[migmartri]

this should return ErrorCasBackendErrorReasonInvalid no?