Allow interceptors to yield and update request arguments

[blowmage]

This change allows Ruby interceptors to modify request values. (Response values are currently passed through the interceptor, and we have no issues modifying those values.) This was encountered while working on supporting OpenCensus in gRPC requests/responses. Specifically, streaming requests/responses are passed as Enumerable values. The approach we would like to take is to wrap the Enumerable with a Lazy Eumerable that will log when a request or response passes through the gRPC client. However, the current implementation does not allow the request Enumerable to be modified.

This change does not pass all the tests. There are some tests that specify that the request is opened before the values are passed through the interceptors. I don't know how to keep this behavior while still allowing interceptors to wrap the request Enumerable. Therefore I am opening this PR to start a discussion on how to move forward.

[blowmage]

We would also like the interceptor to be able to set the OpenCensus gRPC metadata, as well as wrap the streaming requests/responses.

[blowmage]

@apolcyn Have you had a chance to look at this?

[apolcyn]

sorry @blowmage this and #17650 slipped past me. Taking a look

[apolcyn]

Sorry I think I'm missing something here - the test that I see failing is

1) ClientStub #server_streamer via a call operation should send metadata to the server ok when start_call is run first
     Failure/Error: expect(c.metadata[k.to_s]).to eq(v)
       expected: "v1"
            got: nil

to be sure, is this the test in question?

[apolcyn]

@blowmage I should add, can we please add a test here? A test will help my understanding of this change for review. Regarding your comment, if we can find a backwards compatible way to make this change, then it should be ok; if it's breaking, we can evaluate. However, if this becomes a significant API addition or a breaking change, we'll need to at least at some point have a gRFC for too.

[blowmage]

Yeah, I'm still trying to get the grpc ruby code to build and pass cleanly on OS X. I may have to bail on OS X and move this to a Linux VM.

Which Kokoro build includes the Ruby tests?

[apolcyn]

We have mac and linux Kokoro builds for automated CI:

see https://github.com/grpc/grpc/blob/master/tools/internal_ci/linux/grpc_basictests_multilang.cfg
and https://github.com/grpc/grpc/blob/master/tools/internal_ci/macos/grpc_basictests_objc_dbg.cfg and https://github.com/grpc/grpc/blob/master/tools/internal_ci/macos/grpc_basictests_objc_opt.cfg

[blowmage]

I see ruby test output in the "Basic Tests Multi-language Linux (internal CI)" build, but I don't see the ruby test output in any of the builds for MacOS or Windows.

[stale]

This issue/PR has been automatically marked as stale because it has not had any update (including commits, comments, labels, milestones, etc) for 180 days. It will be closed automatically if no further update occurs in 1 day. Thank you for your contributions!

[blowmage]

This is the call that is causing the tests to fail. The metadata is sent before the interceptors have a chance to run and add additional metadata values.

[stale]

This issue/PR has been automatically marked as stale because it has not had any update (including commits, comments, labels, milestones, etc) for 180 days. It will be closed automatically if no further update occurs in 1 day. Thank you for your contributions!