Improve rpc_soak and channel_soak test to cover streaming

[zbilun]

• PTAL @apolcyn
• The clientCompressedStreaming and serverCompressedStreaming cases are not included in this version of the PR but will be added if necessary.
• In this design, the large_unary soak test case will continue to use the blocking API, while the streaming test cases will use the non-blocking API.
• A new test type parameter has been introduced to the performSoakTest function.
• Please review the POC code, and we can discuss the design further, thanks!

[apolcyn]

I'm not sure how much benefit there will really be to running the different RPC types (client streaming, server streaming, etc.) in a loop.

The code paths and behaviors exercised are going to be very similar to the unary based soak tests we already have.

Here is a straw man idea for what I think might be useful here:

• using a long-lived stream
• start the stream once (per thread). On each soak iteration, send one message and receive one message.
• If/when the stream fails, indicate it in the log, but otherwise restart the stream and continue on the new one.

This would provide us a new dimension of test coverage that we don't currently have much of (long lived RPCs).