Send directive & span definitions to extension

[JosephVolosin]

Based on an issue I opened, #1999, this PR updates the request sent by callExtension two ways:

• Instead of sending the selected directive ID, the full directive definition is sent
• A new field, selectedSimulatedActivity, is sent

selectedSimulatedActivity represents the span that is either selected in the UI, or the span that is tied to the selected directive. This lets users directly send simulated activities to their extension, as well as including the simulated activity if it exists even when the directive is selected.

The directive ID was changed to the full definition to remove the extra hop of having the extension receive the ID and have to request the directive's definition

These two changes should compress extension workflows - for example, the current workflow used for an extension I'm building is:

callExtension -> passes directive.id to my API -> API requests directive definition from PlanDev + API requests simulated activity definition from PlanDev

Testing

Small Python server to work as an extension is included as an artifact: mock-extension-server.py

1. Run Python server: python3 mock_extension.py
2. Nagivate to Hasura -> Data -> ui -> extension -> Insert Row
3. Fill out row details - only field you specifically need is url to be set to http://localhost:8000 (default port for the test extension)
4. Save
5. Navigate to ui -> extension_roles -> Insert Row
6. Fill out row details - admin (or your role) needs access to the extension we just created via. the extension_id
7. Navigate to PlanDev
8. Create a plan, open the plan
9. Add an activity, run simulation
10. Select the activity, then click Extensions and select the example extension
11. The Python server should show the directive definition and span definition
12. Select the span, then click Extensions and select the example
13. The Python server should again show the directive definition and span definition

[JosephVolosin]

Some things I'd like to discuss on this:

1. Is there a specific reason we were previously sending just the ID?
2. This update removes backwards compatibility (ID is now located underneath the selectedActivityDirective). Is this ok?
3. Should we always try to send the simulated activity? Should we allow extensions to define the arguments they want sent (probably another, bigger PR to solve this)

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[AaronPlave]

Some things I'd like to discuss on this:

1. Is there a specific reason we were previously sending just the ID?
2. This update removes backwards compatibility (ID is now located underneath the selectedActivityDirective). Is this ok?
3. Should we always try to send the simulated activity? Should we allow extensions to define the arguments they want sent (probably another, bigger PR to solve this)

1+2. I'd have to go back and look but it is quite possible that some folks rely on this ID right now. I'd recommend retaining the ID for backwards compatibility.
3. I think it is reasonable to always send both the span and directive if either exist (may have a span without a directive in non-merlin uploaded sim cases, coming soon..). However I'd also consider generalizing the extension selection a bit to also hit #1998. Something like:

export type ExtensionPayload = {
  version: 1; // would be nice to finally version this

  planId: number;
  simulationDatasetId: number | null;

  selection: {
    primary: ExtensionPrimarySelection | null;

    activityDirectives: ExtensionActivityDirective[]; // could just throw the whole object in here, same with below, though they can change over time..
    simulatedActivities: ExtensionSimulatedActivity[];
    externalEvents: ExtensionExternalEvent[];
  };

  /** @deprecated but here for compatibility */
  selectedActivityDirectiveId: number | null;

  gateway?: string;
  hasura?: string;
};

// for directives/spans - indicate which is selected and also optionally include the associated span/directive
export type ExtensionPrimarySelection =
  | {
      kind: 'activityDirective';
      activityDirective: ExtensionActivityDirective;
      simulatedActivity: ExtensionSimulatedActivity | null;
    }
  | {
      kind: 'simulatedActivity';
      simulatedActivity: ExtensionSimulatedActivity;
      activityDirective: ExtensionActivityDirective | null;
    }
  | {
      kind: 'externalEvent';
      externalEvent: ExtensionExternalEvent;
    };

We'd need to make a few changes to support getting a list of directives, spans, and external events here:

1. Activity directives: already has multi-select state in ActivityDirectivesTable, can promote that to a store in activities.ts like selectedActivityDirectiveIds and bind the table to it. Not actually mutated by ag-grid so this should be safe.
2. Need to add multi-select to spans table, a backing store in simulation.ts, and see if the table context menu needs to be updated to watch out for multi select (like not showing various actions if multiple spans are selected)
3. Same as 2, add store, bind to table, check context menu if one exists for that table.