Jobs Index Page: Live Updates + Pagination

[philrenaud]

A new way of handling some long-needed upgrades to the Jobs Index page in the web UI:

• Live updates to jobs in your cluster (new jobs, GC'd jobs)
• Current (rather than historic) status of those jobs (Show allocation status for only those expected to be running, rather than a long history from state)
• Real pagination, filtering, and searching against the server, rather than loading every job into the browser

This has also included some side-effect features that we think will be a big improvement to web UI quality of life:

• Updated Job Status concepts, to surface job conditions like Degraded and Recovering instead of Running | Dead | Pending.
• A dedicated User Settings section in the profile nav where you can view and set localStorage settings for a few new features
• Parent jobs (parameterized, periodic) no longer eagerly loading child jobs at the /jobs index level, freeing up quite a lot of bandwidth for common use-cases

---

General methodology:

• The /jobs/index route's model kicks off a GET /statuses query aimed at getting all jobs indexes with your current params, like namespace, etc. Not blocking, just initializing.
• Once returned, we take the jobIDs and nextToken from that and set them on the /jobs/index controller, then kick off the controller's watchJobs and watchJobIDs methods
• controller:
  • watchJobIDs:
    • runs a blocking GET /statuses query with an ?index first set by the route's model method
    • Upon receiving a response:
      • Updates query index (property on controller)
      • Updates this.nextToken (to allow pagination)
      • If the user allows jostling (default true; localStorage liveUpdatesEnabled):
        • Updates this.jobIDs
        • Kicks off this.watchJobs
      • Otherwise:
        • Updates this.pendingJobIDs/pendingJobs and gives the user a button to press to kick off this.watchJobs
  • watchJobs:
    • runs a blocking POST /statuses with an ?index set from the most recent watchJobIDs GET
    • Upon receiving a response:
      • Refreshes what the user sees in the jobs table
  • Watches for changes to filters (namespace, node pool, etc.) and aborts/re-runs watchJobIDs when they change
• watch-list service:
  • Stores AbortControllers for jobsIndexIDsController and jobsIndexDetailsController, so that we may cancel them and re-set them as needed when something changes remotely (a job gets GC'd, say)
    • These get aborted via the route's willTransition method (so that we're not keeping blocking queries open when you're off-page), and aborted/re-set when a new watchJobIDs or watchJobs happens (on unblock because of new data)
• Job Adapter:
  • Splits query requests (from watchJobIDs and watchJobs) to be either GET or POST respectively
  • On POST, generates a unique hash based on requestBody and uses that as a key in the watch-list service for future index lookups[b][c][d][e]
• Job Serializer:
  • Normalizes the response from watchJobs to account for "jobs you requested but we don't have any info about", to show the user an unclickable 'Probably garbage collected/purged" row in the table
  • Take the Allocs data for each job and shape them like other Allocations[f][g] in the app. In this way, we can make determinations about a job's health, version, etc. from the index page.

(Re-do of #19778 before I borked the rebase)

[github-actions]

Ember Test Audit comparison

	main	ec5be26	change
passes	1550	1559	+9
failures	0	0	0
flaky	0	0	0
duration	10m 41s 926ms	11m 30s 226ms	+48s 300ms

[gulducat]

Bring on those live updates! 👏

[github-actions]

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.