Adding a test to ensure data streams respect TcpClientReceiveResponseTransmissionAfterInitialReadTimeout

[sburmanoctopus]

[sc-42848]

Background

We wanted to make sure data streams respected the new TcpClientReceiveResponseTransmissionAfterInitialReadTimeout. Turns out they did. So let's write a test to prove it.

The data streams work because MessageExchangeStream.ReceiveResponseAsync calls ReceiveAsync using the new timeouts, and ReceiveAsync calls ReadStreamsAsync. So the timeouts are in place already.

public async Task<ResponseMessage> ReceiveResponseAsync(CancellationToken cancellationToken)
{
    // Wait for data to become available using existing timeouts, then once we have data streaming in, use the smaller timeout (so we do not wait as long if an error happens here).
    await stream.WithReadTimeout(
        halibutTimeoutsAndLimits.TcpClientReceiveResponseTimeout,
        async () => await stream.WaitForDataToBeAvailableAsync(cancellationToken));

    return await stream.WithReadTimeout(
        halibutTimeoutsAndLimits.TcpClientReceiveResponseTransmissionAfterInitialReadTimeout,
        async () => await ReceiveAsync<ResponseMessage>(cancellationToken));
}

async Task<T> ReceiveAsync<T>(CancellationToken cancellationToken)
{
    var (result, dataStreams) = await serializer.ReadMessageAsync<T>(stream, cancellationToken);
    await ReadStreamsAsync(dataStreams, cancellationToken);
    log.Write(EventType.Diagnostic, "Received: {0}", result);
    return result;
}

How to review this PR

Quality :heavy_check_mark:

Pre-requisites

• [ ] I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
• [ ] I have considered informing or consulting the right people, according to the ownership map.
• [ ] I have considered appropriate testing for my change.

[sburmanoctopus]

@LukeButters , I also ninja'd in a namespace change, as the version in the project name and namespace did not align 😁

[shortcut-integration[bot]]

This pull request has been linked to Shortcut Story #42848: Significantly reduce the current TCP Timeout of 10 minutes (not control messages).