Related Issue

Unary RPC : The code for this has been merged earlier. It stores the request and response in a map where ;
key =>( stream-id ) & value => {struct} (containing request and response related data) .
Limitations to this structure :
We were unable to modify data in a nested structure , which means if you need to append data (in case ,data is transmitted in streams) , we have to make a copy of the value , make modification to it and reassign the value to the particular stream-id .
This can increase time and space for processing a particular request .
Closes: #1782

Describe the changes you've made

Revised Approach :
We anyways need map structure so , a other way around to work on the chunks of data is to maintain a singly linked-list where each node contains the data for particular transmission and a pointer to the previous node ( transmission) .
And upon getting the signal that the stream has ended , we can backtrack to make an array of the final DATA stream .
For the mock-matching part : a similar matching technique to unary RPC has been used .
Note : when run in test mode , server always acts as unary RPC by combining the streams of message from mocks into a single stream .
You can checkout the feature :
https://github.com/aerowisca/keploy/tree/streaming_grpc
For sample app:
https://github.com/aerowisca/samples-go/tree/grpc_goRoute/grpc
The functions in the client handler function of the samples app are as follow:
1.unary 2. Client side streaming 3. Server side streaming 4. Bidirectional

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, local variables)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Please let us know if any test cases are added

Please describe the tests(if any). Provide instructions how its affecting the coverage.

Describe if there is any unusual behaviour of your code(Write NA if there isn't)

I am not sure as what to do with the unrecorded calls , like if the method has been deprecated and there are no relevant mocks for that request ! (currently the application terminates without moving forward with the remaining testcases) but in my opinion it should leave that testcase and move forward with other testcase and prepare a final summary including the test with zero mocks.

Checklist:

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.