[Connectors][UI] Update connectors list UI for connectors that are not enabled after import

[ymao1]

In order to support import/export of connectors, we need to ability to allow users to fix connectors that have been disabled due to import.

1. Disabled state for connectors that are not enabled after import in connector list

We already have a disabled state for connectors disabled due to config or disabled due to license. We should use the same disabled state but have the message reflect this type of disabled state

2. Action for "fixing" disabled connector in each row in the connector list.

This could be similar to how we show a "Fix" link on the rule list for license errors, where clicking the "Fix" link will open the edit flyout where a user would have to re-enter the secrets to update the connector. Since update already does validation on the secrets field, the user won't be able to "fix" the connector without entering secrets. It would maybe be nice if the edit flyout showed an additional prompt related to this specific scenario ("Reenter secrets to re-enable this imported connector"?)

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[ymao1]

Blocked by #94106

[YulNaumenko]

@mdefazio could you please help us with the design for displaying connectors which doesn't have a secrets after import. We should warn the users that this connector is not possible to use till the secrets will be updated. I'm not sure if we need a banner or directly highlight the connectors list rows, or both :-).
Do you think to have it disabled highlight is a clear approach? Like proposed in the description, in this case we need a Fix button, because Edit won't be available.

[YulNaumenko]

@ymao1 I think we also need to include to the scope of this issue filtering of the available connectors from the rule actions select connector dropdown to avoid the issues with attaching non working connector to the action.

[ymao1]

I have this issue for handling this within the create/edit rule fly out. Is that similar to what you were thinking?

[YulNaumenko]

Agree, #94128 is covering this use case