tor-proto,tor-cell: Code refactoring and add support for sending XOFF messages
This MR adds support for sending XOFF messages when the amount of stream data bytes in the stream queue becomes too large.
The first few commits do some refactoring. The main changes are:
- removes the
flowctl-cc
feature oftor-proto
- this makes the
tor_proto::relaycell::flow_ctrl
module stable, including the XON/XOFF cell types
- this makes the
- rename
CtrlMsg::SendSendme
toCtrlMsg::FlowCtrlUpdate
and make it extensible- we'll use this in the future to send XON messages in addition to SENDME messages
- rename
StreamSendFlowControl
toStreamFlowControl
- combine some objects into a
StreamComponents
to try to make the code simpler
The code changes/additions are:
- change
UnparsedRelayMsg::data_len
to return aResult
, and to return 0 if the cell is not a RELAY_DATA cell- there are two reasons for this:
- the max length allowed may be different for different cell versions, and there's no way for the caller to know what cell version the
UnparsedRelayMsg
came from - by ensuring we only return a valid length, and we don't return a non-zero length for non-data cells, we hopefully prevent future bugs
- the max length allowed may be different for different cell versions, and there's no way for the caller to know what cell version the
- there was some discussion related to this in !2976 (comment 3194933) (/cc @nickm)
- there are two reasons for this:
- add wrappers around the stream mpsc channel to track how many stream data bytes are queued
- add support for sending XOFF messages
/cc @gabi-250 as there are circuit reactor changes here.