[ResponseOps][Cases][Meta] Case connectors support with bidirectional sync to 3rd parties

[shanisagiv1]

Describe the feature:
To support a better incident closure and for better Kibana case enrichment (using other tools' knowledge). we'd like to support a bidirectional sync between our kibana cases and the 3rd parties.
To allow that we need to improve our connector framework and adjust each connector to map between the target system and the case fields. Not all the fields will be synced as a first iteration. The only fields to be synced are Case Status and Case Severity.

User Stories:
Flows in the Case view

• As a user, I'd like to push my Kibana Case to a 3rd party, and for any change in status or severity, the Kibana case should be updated accordingly.
• As a user, I'd like to see all sync triggers in the activity list(under the History tab) only if there is an update to the case or the external service. For example, when the case status is changed manually and synced to the 3rd party.
• As a user, I'd like to see all the updates received from a 3rd party in the activity list(under the History tab). The last update timestamp should be presented next to the connector name in the right panel.
• As a user, in case I have more than 1 set connector I have to select which one is the primary connector since we can't manage bidi sync to more than 1 connector.
  • When selecting the connector for the first time on the case view, we should ask the user to determine which is the
    Primary connector for the directionality. Then let the user select the connector and and the other fields.
  • The user will be able to change it if he removes all connectors from the case and starts from scratch.
• As a user, I’d like the assigned alerts to a case to be closed auto when the case is closed. This should be customized vis Case Setting and should be available just for Security Cases.

Flows in Connector Setting:

• Today, we allow "auto-case closure" when a case is pushed to a 3rd party. This flow does make any sense when talking about BiDi sync ( since the case is closed right after the triggering and it will close the ticket accordingly, we want the status to be synced by the 3rd party and not automatically) - This means we should not allow this option when Bi-Di sync is set for the connector. We should add a note to this option that once it's selected it will work only with "one-way sync".
• Today, we allow more than 1 connector to be triggered from the Case. For example, the user can push the case to Jira Ticket and right afterward push the same case to SNOW. This also does not make any sense since we cannot keep all systems synced. The user should decide on the primary connector. This should be set on the Case level and not on the global level since customers might use multiple vendors for different purposes so each Case type can be synced with other tools.

Open Questions:

• Should we start with all connector types in the first iteration? or just with the ITSM most common? Does that change the efforts somehow? (I guess just when mapping the fields?). The recommendation is to start just with ITSMs
• Should we have the mapping fields form as part of the Setting per connector? or as part of the setup in the case view when triggering a connector. since today the other fields are set in the case.. My gut is that it should be consistent so better to have it in the setting. e.g which Case status values are mapped to which Jira status values (same for severity)
• What timelines should we expect for syncs? As of today when connector is pushed and synced back with the link?
• Do we want to support as part of this - the ability to "stop" the syncing and "start" syncing again - this is useful in case of too much noise.

Reference to original BiDi sync full scope

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)