[dashboard, (server?)] Inconsistent derivation of prebuild status

[geropl]

This leads to inconsistencies in our UI (prebuild says "FAILED", but re-triggering yields "cannot start - still running") and strange errors (hanging on prebuild logs).

Examples where we're interested in the state/properties of a prebuild, but use different sources:

• PrebuildLogs
• Prebuilds, 2,
• protocol
• bridge
• PrebuildLogs
• PrebuildLogs
• PrebuildStatusMaintainer

I don't think that all of those usages are wrong per-se, but I think the fact that we see such a variety of ways to answer the same question is a strong hint that our data model/API lags functionality or reliability.
IMO it's worth going through all cases and understand the motivation and problems that the current API poses and fix those.

[geropl]

/cc @jldec I tried to dig up all places in the code I could think off. Might still be incomplete.

[jldec]

Thanks @geropl - I agree and made a similar comment earlier today.

The inconsistent behavior of prebuild status and logs is adding to the perception of prebuild unreliability.

[geropl]

A concrete bug caused by this: #8592

[easyCZ]

Out of the instances listed, only the following remain:

• https://github.com/gitpod-io/gitpod/blob/main/components/dashboard/src/components/PrebuildLogs.tsx#L87
• https://github.com/gitpod-io/gitpod/blob/main/components/ws-manager-bridge/ee/src/bridge.ts#L82 This one is less of a concern as it is a derivation from the underlying Workspace Instance Status which has to happen
• https://github.com/gitpod-io/gitpod/blob/main/components/dashboard/src/projects/Prebuild.tsx#L188 which is being tackled in [dashboard]: Use prebuild record when determining prebuild actions #8841