Introduce ActionRunAttempt to represent each execution of a run

[Zettat123]

This PR introduces a new ActionRunAttempt model and makes Actions execution attempt-scoped.

Main Changes

• Each workflow run trigger generates a new ActionRunAttempt. The triggered jobs are then associated with this new ActionRunAttempt record.
• Each rerun now creates:
  • a new ActionRunAttempt record for the workflow run
  • a full new set of ActionRunJob records for the new ActionRunAttempt
    • For jobs that need to be rerun, the new job records are created as runnable jobs in the new attempt.
    • For jobs that do not need to be rerun, new job records are still created in the new attempt, but they reuse the result of the previous attempt instead of executing again.
• Introduce rerunPlan to manage each rerun and refactored rerun flow into a two-phase plan-based model:
  • buildRerunPlan
  • execRerunPlan
• Converted artifacts from run-scoped to attempt-scoped:
  • uploads are now associated with RunAttemptID
  • listing, download, and deletion resolve against the current attempt
• Added attempt-aware web Actions views:
  • the default run page shows the latest attempt (/actions/runs/{run_id})
  • previous attempt pages show jobs and artifacts for that attempt (/actions/runs/{run_id}/attempts/{attempt_num})

Compatibility

• Existing legacy runs use LatestAttemptID = 0 and legacy jobs use RunAttemptID = 0. Therefore, these fields can be used to identify legacy runs and jobs and provide backward compatibility.
• Existing artifact records are not backfilled; legacy artifacts continue to use RunAttemptID = 0.

Improvements

• It is now easier to inspect and download logs from previous attempts.
• run_attempt semantics are now aligned with GitHub.

  • A unique number for each attempt of a particular workflow run in a repository. This number begins at 1 for the workflow run's first attempt, and increments with each re-run.

• Rerun behavior is now clearer and more explicit.
  • Instead of mutating the status of previous jobs in place, each rerun creates a new attempt with a full new set of job records.
• Artifacts produced by different reruns can now be listed separately.

TODO

• Support query run/job by attempt via API
• Improve tests
  • concurrency
  • rerun
  • artifacts
  • new APIs

Screenshots

Latest attempt:

Previous attempt (rerun is not allowed):

Dropdown for attempt records:

[bircni]

UpdateRunAttempt calls UpdateRun again to sync status/started/stopped. That's three writes to action_run inside one transaction.

[Zettat123]

Yes, I’ve noticed that issue as well. In this function, we need to create/update the same ActionRun record three times.

1. Create the ActionRun to get ActionRun.ID
2. Use ActionRun.ID to create a RunAttempt and write RunAttempt.ID back to ActionRun.LatestAttemptID
3. After all the jobs are created, update ActionRun.Status (via UpdateRunAttempt)

I'm not sure of a better way to handle this yet - any ideas are welcome.