Support associating request and response messages

[nhawke]

Currently, the replayer tool only needs either a response or a request message for each RPC (e.g. gNMI Get only needs the response, gNMI Set only needs the Request). However, some operations may require both the request and response to recreate the RPC. For example. this can be the case when a response message is being replayed as a "snapshot" as a request, but the original request associated with that response contains some necessary information.

Due to the limitations of the replay log format, there is no way to pair up requests and responses with 100% certainty. Consider this sequence of events in a log:

SomeRPC
XRequest
XResponse
SomeRPC
SomeRPC
YRequest
YRequest
YResponse
YResponse
SomeRPC

In this sequence, we can reasonably assume that the XRequest is associated with the XResponse, but we cannot determine which YRequest is associated with which YResponse.

There are two general strategies to resolve this problem:

1. In the sequence of events, include a header entry before each message entry. This header can contain metadata such as a "event ID". If both a request and a response proto have the same event ID, they are considered as coming from the same RPC call.

2. Change the binary log format used by this tool from being a simple array of entries to being an array of custom types which can carry more metadata. This would also provide some flexibility in the future to add more metadata to logs rather than needing to work within the constraints of the existing format. A new format might roughly look like this:

message ReplayLog {
  repeated Entry entries = 1;
}

message Entry {
  string rpc_name = 1;

  bytes request_data = 2;
  google.protobuf.Timestamp request_timestamp = 3;

  bytes response_data = 4;
  google.protobuf.Timestamp response_timestamp = 5;
}

As of writing, there is no use case which requires this functionality. However, we can consider these changes if the need arises.