[ui] Splitting deployment allocs by status, health, and canary status

[philrenaud]

Instead of just splitting by alloc.clientStatus, we now split by multiple factors and give indicators/icons as such.

This splits allocBlocks objects in both the "steady" and "deploying" panels into an object format like this:

allocBlocks = {
  running: {
    healthy: {
      nonCanary: [Allocation, Allocation, Allocation],
      canary: [Allocation],
    },
    unhealthy: {
      nonCanary: [],
      canary: [],
    },
  },
  pending: {
    healthy: {
      nonCanary: [Allocation, Allocation, Allocation],
      canary: [],
    },
    unhealthy: {
      nonCanary: [],
      canary: [],
    },
  },
  failed: {
    healthy: {
      nonCanary: [],
      canary: [],
    },
    unhealthy: {
      nonCanary: [],
      canary: [],
    },
  },
  unplaced: {
    healthy: {
      nonCanary: [Allocation, Allocation, Allocation],
      canary: [],
    },
    unhealthy: {
      nonCanary: [],
      canary: [],
    },
  },
  complete: {
    healthy: {
      nonCanary: [],
      canary: [],
    },
    unhealthy: {
      nonCanary: [],
      canary: [],
    },
  },
}

Since we're also allowing for many more sub-categories when displaying these allocation blocks, we've also established a new rule with minimum block size. We'll no longer have an arbitrary threshold at which it splits into "aggregate/summary" view (was 50 blocks), now it will depend on a user's screen width.

Resolves #16724

[github-actions]

Ember Asset Size action

As of 1bbb2e7

Files that got Bigger 🚨:

File	raw	gzip
nomad-ui.js	+10.3 kB	+1.73 kB
nomad-ui.css	+2.13 kB	+282 B

Files that stayed the same size 🤷‍:

File	raw	gzip
vendor.js	0 B	0 B
vendor.css	0 B	0 B

[github-actions]

Ember Test Audit comparison

	16350-service-job-deployment-status-panel	1bbb2e7	change
passes	1494	212	-1282
failures	0	1	+1
flaky	0	0	0
duration	11m 42s 370ms	000ms	-11m 42s 370ms

[ChaiWithJai]

Looking good. I've spent a long time reviewing this block of work... I think the derived state computations based on allocBlock are getting to be pretty significant at this point. Have you consider extracting this into its own class?

[ChaiWithJai]

nit: These could be combined.

[philrenaud]

Something like {{#if (and (eq @status "running") (not @steady))}} ?

[ChaiWithJai]

Yep!

[ChaiWithJai]

thought: I think it might be time to really consider what allocBlock is doing and encapsulate that behavior into its own class. As we get deeper into computing derived state, I imagine we'll run into reactivity issues where we're inadvertently showing stale data. And that's already one of the challenges and reasons why we're considering long-polling the allocations associated to a specific deployment. We do this already for the AllocationStatsTracker.

This would really come in handy if we ever redesigned the Job Overview Page because we'd decouple the computation of the logic out the component. Or if we wanted to quickly follow on the feature and expand this into another view like this:

[philrenaud]

This is a good suggestion, and AllocationStatsTracker is a good analogue. I'm going to set up a class-based refactor for this in a separate PR.