feat(dataplanes): adds service links to outbound traffic cards

[johncowen]

What

I think, but not totally sure that this closes #2848 edit: It doesn't close it yet.

At a high level this PR adds work to allow us to eventually add [Mesh*Service]:name badges/links to the top-right of outbound traffic cards in the new KRI enabled Traffic view only. I removed where I was using this, but kept everything as I'm sure we will use this in the future and for other features.

Note: this PR doesn't currently include the new badge/link above as we are awaiting kumahq/kuma#13882

At a lower level I had to/wanted to do a few things to make this generalized and easier to do at an application level (i.e. as an application engineer). This means making it easy to make a link from a KRI, by just writing:

<XAction :href="kri://${kri}" />

and having things Just Work(tm)

Implementation

Browsers have a feature called registerProtocolHandler https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler, but it only works in a secure context i.e. HTTPS, something we can't guarantee ourselves. The implementation is loosely modelled on this idea.

• XAction supports an injectable protocolHandler, via which we can turn things like kri://blah_blah_blah_etc into /mesh/name/mesh-services/name ie. handle a kri:// protocol and convert it into a normal http:// one. This leaves us with a <a/> with a correct http URL, but this does not automatically get handled by vue's router.
• Because normal links aren't handled by vue's router automatically, the protocolHandler also registers a global click handler. This only acts on special data-* tagged links, i.e. its opt in, and we only currently use it for very specific links. The click handler prevents the default browser link that would not use the History API and instead passes it through to Vue's router, which does use the History API.
• We can then "register" certain KRI "kinds" with route names for example msvc should always go to mesh-service-detail-view (we might need to be able to have multiple potential route names at some point in the future, but I have a plan to deal with that if we ever need to)

Apart from this I made a few other changes to our Kri parser while I was here:

• shortName feels like something to do with the name of the thing, whereas its really the kind (a short name for the kind, but in the context of the KRI we don't have the longKind so I called it just kind) I rolled this back, we figure we should stick to the word shortName as thats what the backend uses.
• I added id which is name.namespace (if namespace exists). We should always use this for linking like we do with our nonKRI'd resources. I moved this into the protocolHandler instead
• I exported Kri from @/app/kuma. If we want to turn all these things into proper packages, we should try and treat them as packages now, then there will be less to do when we move them out.

Oh lastly, I put most of this into the service-mesh module just for ease and less plumbing, I would guess I will probably move this around a little at a later date and make it so you can add multiple protocolHandlers (i.e. compose them)

P.S. I noticed reviewing will be a tiny bit easier if you "Hide Whitespace" in GH

[netlify]

✅ Deploy Preview for kuma-gui ready!

Name	Link
🔨 Latest commit	4620a0a
🔍 Latest deploy log	https://app.netlify.com/projects/kuma-gui/deploys/68cd54875ba7f100082e5968
😎 Deploy Preview	https://deploy-preview-4256--kuma-gui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[johncowen]

We could also do with this happening for this to be usable across all KRI linking (so not restricted to meshservice types)

[johncowen]

Couple of upstream issues that are relevant here that we wanted to link to:

• Create an endpoint to retrieve a resource by its KRI kuma#13882
• Add shortName of resource types to _resources endpoint kuma#14380

[johncowen]

Notes: