Propagate backlinks on Signal and Signal-with-Start responses

[long-nt-tran]

What changed?

With these PRs to add the link field on these responses protobufs:

• Add link field to propagate backlink in signal and signal-with-start responses api#761
• Go codegen for propagating backlink for signal and signal-with-start api-go#247

This PR adds logic from the server that does the following:

• Change internal history protos to attach link on signal and signal-with-start responses and make proto
• Update history API handlers for signalworkflow and signalwithstartworkflow to propagate the link from request back to the history response
• Update the frontend API handlers for signal and signal-with-start to propagate the link from the history response
• Opportunistic refactoring of link generation to link_util.go

Note

From discussion w/ @Quinn-With-Two-Ns since signals are buffered, the link is generated with a reference to the RequestId rather than EventId.

Why?

This will enable the caller of the signal to have a backlink to the cross-namespace signal invoked, which will become more relevant for Nexus SDK ergonomics.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

Unit tests

$ go test ./service/history/api/signalworkflow/ -run TestSignalWorkflowSuite -count=1
ok      go.temporal.io/server/service/history/api/signalworkflow        0.893s

$ go test ./service/history/api/signalwithstartworkflow/ -run TestInvokeSignalWithStartSuite -count=1
ok      go.temporal.io/server/service/history/api/signalwithstartworkflow       0.860s

Functional tests

$ go test ./tests/ -run TestLinksTestSuite
ok      go.temporal.io/server/tests     1.486s

Potential risks

Need to test end-to-end to see that the link shows up correctly in the Web UI.

[long-nt-tran]

only pointing to my fork for CI tests, will wait for temporalio/api#761 and subsequent api-go codegen to be merged and then remove these before I merge this PR

[bergundy]

Here's what's missing:

• Adding to the map that tracks request ID to event ID
• A functional test that verifies that request IDs for all of these requests are added to the map
• Ensure that the workflow start link is only populated if an execution was started

[bergundy]

A test that's all mocked out doesn't provide a ton of value IMHO. Just test this with functional tests in the tests/ directory.

[bergundy]

Same as above.