[Kibana] Suites tab on overview page

[andrewvc]

NEW PLAN

After discussing with @liciavale it makes more sense to not implement this flow but the forthcoming suites management flow, which is closer to the new synthetics app and thus will be less effort with maximal code re-use. Let's pause on this till the right issue is filed there.

IGNORE BELOW

This supercedes #431 in solving elastic/beats#27924 .

Blocked on elastic/beats#29917

After a discussion with @liciavale , with a follow-up with @liciavale @paulb-elastic and @drewpost we agreed that the generic error facility mentioned in #431 had too many downsides to proceed with. The main issue is that dealing with history is strange, and we still have a weird UX due to the lake of symmetry between the upcoming monitor management UI and the overview page.

We want to keep on working on this problem for the future synthetics app, but for the immediate future we propose the following ACs:

• Add a new tab allowing you to switch from the current monitors table on the uptime overview page to a new 'suites' table.
• List all suites in a new suites table when the tab is clicked.
• The columns for that table would be:
  1. Suite Name
  2. Source: An abbreviated version of the source, usually a URL
  3. Errors: Either the last received error or the text "No current errors" if none present
  4. Monitors: A link to the overview page filtered (via KQL) to show all monitors contained by the suite
  5. If it is easy to add a "All | With Errors" filter to the new suites tab let's do it, if not, let's not
  6. Timestamp of last suite run
• To support these features heartbeat would issue a new type of suite run document, probably just the same way a monitor runs before each suite run.
  - We determined that the status of a suite was not the sum of all jobs statuses, but rather that suites would not have a status, just a notion of current errors.
• Suite errors should not trigger existing alerting rules, adding alerts will be a todo for a future issue
• Mappings updated for new suites doc field

Given that our current design resources are limited, we're only going to be reaching out to @liciavale for approval on this and try for a lightweight iterative review process.

The changes to the current page would be something like what's listed below.

[andrewvc]

TODO: Make a follow-up issue to cover displaying those errors in monitor management

[paulb-elastic]

TODO: Make a follow-up issue to cover displaying those errors in monitor management

#438 raised

[lucasfcosta]

As we have discussed in elastic/synthetics#451, we'll proceed with the term suites for now.

It seems like @liciavale has already taken care of separating the suite creation flow from the individual monitor creation flow, and, therefore, this issue already adheres to the terminology set in the aforementioned issue.

From a terminology point-of-view, no further refinement is needed.

As also mentioned in the issue linked above, there are still concerns with regards to when to implement suites.

[andrewvc]

Closing in favor of elastic/synthetics#470