GRPC Service Proxy and Encoding Interceptor

[robholland]

What was changed

Added a proxy which wires together a GRPC server and client for WorkflowService.

Why?

This allows users to build proxies for Temporal Frontend traffic and use GRPC interceptors to manipulate requests or responses. One use case for this is to centralise data encoding.

Checklist

1. How was this tested:

2. Any docs updates needed?

[robholland]

I've got an auto-generated version of the interceptor nearly working which would use an opt-out approach to exclude Payload(s) we don't want to be touched. Chad has suggested a test which will re-walk the API definitions and check if the list on which the interceptor is built has drifted from the current API version so that we can ensure decisions are made about new Payload(s) as they are introduced (or removed for that matter).

[bergundy]

Which payloads do we not want to touch?

[robholland]

SearchAttributes is the only one I'm aware of.

[cretz]

When temporalio/api#153 lands, it'll be a good example of whether the test will fail when we upgrade the API dependency but don't re-gen code.

[bergundy]

I've got an auto-generated version of the interceptor nearly working which would use an opt-out approach to exclude Payload(s) we don't want to be touched. Chad has suggested a test which will re-walk the API definitions and check if the list on which the interceptor is built has drifted from the current API version so that we can ensure decisions are made about new Payload(s) as they are introduced (or removed for that matter).

Nice! That's what I was going for

[robholland]

make check now verifies via make generatorcheck that files generated based on the API are not stale.

[cretz]

LGTM! Ignore the coveralls complaint (can squash/merge anyways once you get @bergundy's approval)

[bergundy]

Just approved.
I didn't go over the code again but I understand the new approach which is the right way to go IMO.