feat(coral): Show info to user when they temp can not edit a topic

[programmiri]

About this change - What it does

There are cases where a user is allowed to edit a topic/connector in general, because they are topic owner, but the edit functionality is currently blocked because there is an open request. Before now, we didn't show the button in that case.

In line with e.g. promoting a topic, we don't want to hide the button "Edit topic/connector" anymore, but show it disabled and inform the user why they can't edit at the moment. We're doing that by showing a disabled button with a tooltip.

Notes about implementation

First: I sneaked in an unrelated type fix (really no need to make a new PR for one character 😅 ) -> 309495f

Background

• "Edit topic" and "Edit connectors" are links, not buttons (they just look like it)
• <Tooltip /> from DS does not work in strict mode but also without strict mode, it is not really accessible. Screenreader user don't get any information about the tooltip and since we would need to use a Primary.Button with disabled=true, it also does not work for keyboard user.

In order to get the result we want, there is a new (very specific) component DisabledButtonTooltip for this use case. It enables us to have a disabled button or link with accessible tooltips until DS components are updated (and we've disabled strict mode) to cover this use case in a way that it's usable by most users.

Recording

recording-button-disabling.mov

Resolves: #1633

[roope-kar]

LGTM

[roope-kar]

I remember i had issues when working on the DS Tooltip that onMouseLeave would not fire consistently (it was known issue by the internet as well) and had to fallback to tracking onMouseMove and when it leaves the element or something like that.

Though if it works this might be fixed already.

[programmiri]

Oh, I had that too will adding it, but it looked in my case it was because I had a

for tracking the mouse that I had it wrapped around a disabled Button.Primary. After that I did not notice a difference anymore! But I'll do a quick google search and see if that's potential still a problem. Thanks!

[programmiri]

OK I checked and there's no know issue for that general, it seems to happen in some cases (but not 100% clear when) and seems to be dependent on surrounding elements and reactivity (e.g. one explanation was that it could be caused by child elements of the tracking element being added/removed conditionally).

I've checked the functionality in our UI and I was REALLY fast with the mouse 😅 😅 😅 and it worked all the time.