Refactor and polish scope handling in environments table

The following discussion from !80948 (merged) should be addressed:

  • @pslaughter started a discussion: (+1 comment)

    suggestion: Instead of building this property name, I think it'd be preferable to decouple the scope value from this property name. That way we can do things like easily search for stoppedCount to find it's references. 🤔

    We can do a condition here or even create something fancy in the resolver like:

    countsByScope: {
  [SCOPE.AVAILABLE]: available_count,
  [SCOPE.STOPPED]: stopped_count,
},

    WDYT @afontaine?

    how would you feel about saving this for a follow-up to better decouple scope overall? There's a lot of code that is similar in the main component that could benefit from a shared set of utilities mapping scopes to counts, tabs to scopes, and so on.

  • @pslaughter started a discussion: (+2 comments)

    issue (non-blocking): Since the query string technically comes from user land, it might be nice for us to robustly support invalid values for scope=

    Screenshot_from_2022-03-09_13-54-30

    Not necessarily related to this MR 😄

Implementation Plan

TBD...