Fix backlinks in Signal[WithStart]Workflow when called from workflows

[chrsmith]

What changed?

Story time!

• @spkane31 added support for durable calls to SignalWithStart by using Nexus (Implement SignalWithStart as a system nexus endpoint #9833)

• @bergundy pointed out an issue, about how backlinks wouldn't be persisted between the signaler and target workflow. (Implement SignalWithStart as a system nexus endpoint #9833 (comment))

• @long-nt-tran appears to have already added support for that
  (Propagate backlinks on Signal and Signal-with-Start responses #9897)

This PR just adds the final step, and adds tests for verifying SignalWithStart calls are linked correctly.

The only functional changes are in chasm/lib/workflow/nexus_service.go:

1. We weren't setting the SignalLink property in workflowservice.SignalWithStartWorkflowExecutionResponse. We now do.
2. We were manually building the commonpb.Link rather than using the SignalLink returned from the History service's response. I'm assuming trusting the History service is returning a valid SignalLink of the Link_WorkflowEvent variant. (Whether it is a EventID or RequestIDRef is immaterial.)

Why?

Fixes a gap in the new codepath for calls to SignalWithStart adds tests.

Questions

• Is it safe to hard-code EventIDs like this? s.Equal(int64(3), gotReqInfo.GetEventId())

How did you test it?

• built
• run locally and tested manually
• covered by existing tests -- Unknown. I would guess there are "SignalWithStart backlink tests" somewhere, but I didn't find any after a cursory look.
• added new unit test(s)
• added new functional test(s)

Potential risks

I do not know. Please be on the lookout for bad assumptions!

[bergundy]

This LGTM but can you please verify all of these cases via tests?

1. Send a signal-with-start request, no existing workflow, get back a link and the mapping is resolved to an event that is not buffered.
2. Send a signal-with-start request, existing workflow, no running workflow task, get back a link and the mapping is resolved to an event that is not buffered.
3. Send a signal-with-start request, existing workflow, running workflow task, get back a link and the mapping is resolved to an event that is buffered, complete the workflow task, and verify that the mapping is resolved to an event that is not buffered.

To simulate a running workflow task send the request between PollWorkflowTaskQueue and RespondWorkflowTaskCompleted.

[chrsmith]

@bergundy , @long-nt-tran PTAL.

After chatting with you folks, I just did some refactoring and reused the existing test scenarios we had in tests/links_tets.go. However, unifying the { SignalWorkflow, SignalWithStart[ExistingWorkflow], SignalWithStart[NoExistingWorkflow] } into a single test runner was a bridge too far.

So the refactoring went like this:

1.) Introduce a new signalWorkflowTest to eliminate some boilerplate.

New surface area:

type signalWorkflowTest struct {}
func newSignalWorkflowTest(env *testcore.TestEnv, s *LinksSuite) *signalWorkflowTest
func (...) startTargetWorkflow(ctx context.Context) startTargetWorkflowOutput
func (...) startTargetWorkflowWithWorkflowID(ctx context.Context, workflowID string) startTargetWorkflowOutput
func (...) signalWorkflow(ctx context.Context, targetWorkflowID, requestID string) *workflowservice.SignalWorkflowExecutionResponse
func (...) signalWithStartWorkflow(ctx context.Context, targetWorkflowID, requestID string) *workflowservice.SignalWithStartWorkflowExecutionResponse

2.) Refactor the relevant tests to use that new piece of infrastructure. And then for each of those tests, create a SignalWithStart- variant that covers the existing and non-existing workflow case.

 -- PASS: TestLinksTestSuite (0.00s)
    --- PASS: TestLinksTestSuite/TestSignalWorkflowExecution_LinksAttachedToEvent (0.12s)
    --- PASS: TestLinksTestSuite/TestTerminateWorkflow_LinksAttachedToEvent (0.13s)
    --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_LinksAttachedToRelevantEvents (0.13s)
-               ^--- existing test using SignalWithStart, kept as-is.
+    --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_LinksAttachedToEvent (0.00s)
+        --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_LinksAttachedToEvent/SignalStartsNewWorkflow (0.13s)
+        --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_LinksAttachedToEvent/SignalExistingWorkflow (0.13s)
     --- PASS: TestLinksTestSuite/TestRequestCancelWorkflow_LinksAttachedToEvent (0.13s)
+    --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_BufferedDuringWorkflowTask (0.00s)
+        --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_BufferedDuringWorkflowTask/SignalStartsNewWorkflow (0.12s)
+        --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_BufferedDuringWorkflowTask/SignalExistingWorkflow (0.13s)
     --- PASS: TestLinksTestSuite/TestSignalWorkflowExecution_BufferedDuringWorkflowTask (0.13s)
+    --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_BacklinkSurvivesReset (0.00s)
+        --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_BacklinkSurvivesReset/SignalExistingWorkflow (0.14s)
+        --- PASS: TestLinksTestSuite/TestSignalWithStartWorkflowExecution_BacklinkSurvivesReset/SignalStartsNewWorkflow (0.14s)
    --- PASS: TestLinksTestSuite/TestSignalWorkflowExecution_BacklinkSurvivesReset (0.14s)```

[chrsmith]

As it turns out I was calling SignalWithStart the wrong way. I was using the existing frontend API endpoint, and not going through the new system Nexus handler.

Unfortunately making an SDK NexusClient targeting the system Nexus handler isn't possible because of checks baked-into the code. So I had to crib a round about way to invoke the system Nexus handler from another test.

Anyways signalWithStartWorkflow.signalWithStartWorkflow(...) function is kinda crazy, but does what we want it to.

However, there were a couple of quirks with the new SignalWithStart endpoint worth calling out:

• There isn't any way to supply the RequestID. The Nexus handler rejects requests that set the field, and it will be set at runtime. This means that there isn't any idempotent way to send the signal... but I think that might be OK and by-design.
• Similarly, the Nexus handler doesn't allow you to specify any Links in the SignalWithStart request either. I'm not sure of the ramifications of that, but presumably that is OK and by-design as well?