Migrate service proxy and interceptor from SDK

[robholland]

What changed?

Ported gRPC interceptor and proxy code from sdk-go.

Why?

This allows us to keep the proxy and interceptor inline with the API version and allows varying the API version used by SDKs. Previously the large amount of types touched by the interceptor would cause incompatibility when the API changed.

temporalio/sdk-go#971

How did you test it?

Added some tests and adapter sdk-go to use the API code, also with tests.

Potential risks

This should be a no-op, a bug may cause gRPC proxy or interceptors using these APIs to misbehave.

[cretz]

This looks great! Lets get a test or two in here and if you don't mind a GH action to run on each PR just in case (w/ test and lint). I can help here if needed.

[cretz]

Can we also add at least one Go test to the package and run go test on the whole project? This is a sanity check to ensure compilation among other things.

[robholland]

Yep I'll copy/amend the SDK unit tests over this afternoon.

[cretz]

@robholland - we have another use case from temporalio/sdk-go#930. They want to visit every temporal.api.failure.v1.Failure in the proxy. I know it's kinda annoying to ask at last minute, but think we can genericize this a bit? I am wondering if now is the time to do this.

Maybe change VisitPayloads to VisitProtos (I understand we limit to only where payloads are today, is it that troubling to change to walk all protos?). We could still have separate "payload visitor" and "failure visitor" though having some kind of common proto visitor makes more sense, even if it's just interface{} because sometimes it's a slice instead of a proto.Message.

Any design ideas on how best to incorporate failure visiting into the proxy? I have some more detailed thoughts.

[bergundy]

@robholland - we have another use case from temporalio/sdk-go#930. They want to visit every temporal.api.failure.v1.Failure in the proxy. I know it's kinda annoying to ask at last minute, but think we can genericize this a bit? I am wondering if now is the time to do this.

Let’s do this please while we’re touching all of this and avoid the risk of more compilation breaking changes for the Go SDK.

[cretz]

LGTM, but would like @alexshtin and/or @yiminc to take a look

[cretz]

@robholland - we just noticed a bug in the Go SDK version of this where the map[string]*commonpb.Payloads (note the plural) isn't in the switch statement. Can you add it here?

[robholland]

Added.

[alexshtin]

Left some nit style comments. Didn't go much in generator code, but generated code looks good. No human should review reflection and reflection generated code though.