Update VisLayer data models

[ohltyler]

Description

This PR updates the data models for the VisLayers such that we are passing sufficient information to the 'View Events' flyout to render it correctly. Details on the flyout & its mocks are in the related issue #3373

Note there will still be some added field(s) related to error handling - details on that as part of issue #3267

Issues Resolved

Closes #3373

Check List

• All tests pass
• Commits are signed per the DCO using --signoff

[kristenTian]

What would be an example of this urlPath look like?

[ohltyler]

It would be something like anomaly-detection-dashboards#/detectors/<detector-id>/configurations. The base path would come from core services.

Full example:

<EuiLink href={`${getCore().http.basePath.prepend(`${urlPath}`)}`}>{name}</EuiLink>

[joshuarrrr]

@ohltyler Is there an updated design doc for these data models? Mostly just want to make sure our docs stay in sync with these changes that come out of the actual implementation. We also just may want to have a placeholder issue to remind us to document example usage (you may have already created one).

[joshuarrrr]

Is it enough for urlPath to be a static string? In your example, it seems like maybe you'd want to be able to pass something like a detector-id?

[joshuarrrr]

A couple minor questions, but otherwise looks good.

[joshuarrrr]

@ohltyler Is there an updated design doc for these data models? Mostly just want to make sure our docs stay in sync with these changes that come out of the actual implementation. We also just may want to have a placeholder issue to remind us to document example usage (you may have already created one).

[joshuarrrr]

Is it enough for urlPath to be a static string? In your example, it seems like maybe you'd want to be able to pass something like a detector-id?

[ohltyler]

@ohltyler Is there an updated design doc for these data models? Mostly just want to make sure our docs stay in sync with these changes that come out of the actual implementation. We also just may want to have a placeholder issue to remind us to document example usage (you may have already created one).

I'm working on updating the linked View Events flyout issue with details #3155 . From there will have some deeper explanation on these added fields. Is that sufficient? I'm only trying to merge this earlier so there is less interference / less data model changes down the road as plugins integrate.

Is it enough for urlPath to be a static string? In your example, it seems like maybe you'd want to be able to pass something like a detector-id?

I've thought about this, my one concern is I would like to keep it flexible enough for other potential ways a plugin would like to link something. For example, a resource ID may not be necessary (or possible) as part of their url, or maybe they want it to link something related to the resource, but have some different ID there, etc. If we leave as a string it adds no coupling with a resource ID in the url.

[ohltyler]

I'll also open a base meta issue regarding documentation / usage / how to onboard & add it to the feature meta issue.

Update: see #3383