refactor: chunk KOS extend message

[sinui0]

This PR refactors KOS impl to chunk the extension message sent from the Receiver to the Sender.

Closes #97 and tlsnotary/tlsn-utils#10

[th4s]

Wouldn't it be cleaner to handle this in a general way in our messaging layer? Then this change would apply to every sink and stream we are using, while at the same time not mixing the protocol code with IO stuff.

I am thinking of something like wrapper functions in our IoSink and IoStream traits, which break down the payload if needed.

[sinui0]

That thought certainly crossed my mind, but it didn't seem to be quite as straight forward.

1. The IO layer already breaks down the message into chunks. The limit we are running into is mostly regarding deserialization and how much memory a received message is allowed to utilize. This limit needs to be specific to the application context and message type. We could add additional bounds to the IO traits to specify this, but that would make them harder to implement and use. This would be less of a problem with specialization, but that's not in the foreseeable future.
2. A less flexible middleground is to fork tokio_util::codec::length_delimited::LengthDelimitedCodec and make it aware of variant-level size limits, so we could specify a limit specifically for Extend at the codec level rather than baking this into the IO traits. I don't want to block increasing the TLSNotary protocol limit on this work.
3. I think at the end of the day the chunking will get baked into the callsite control flow anyhow. The optimal state of this code would be to generate the matrix in chunks, streaming them, and processing the chunks concurrently. That would require "chunk" message types anyhow. Given our deprecation plans, this is a simpler short-term remedy even if its not actually doing stream processing.

[th4s]

Makes sense 👍, I haven't put that much thought into it when I wrote that.

[th4s]

👍

[themighty1]

gw