fix(apple): buffer unsent tail of partial sendmsg_x calls

[thomaseizinger]

Seeking some early feedback on this. Whilst debugging some performance problems, @jamilbk discovered that we are discarding the return value of sendmsg_x and may thus be silently dropping datagrams if e.g. only 4 out of 32 packets were sent.

In order to retain the current API, I opted for exploring a buffering approach. In case of a partial send, we buffer the remaining tail of the batch and return Ok(()). This will trigger the caller to pass us another Transmit at which point we will first try to flush the buffered tail before continuing on to the next batch.

An alternative would be to surface the partial send to the caller but that would leak into all other platforms.

[thomaseizinger]

Disclaimer: Claude wrote this one, I haven't verified it yet.

[mxinden]

//CC @larseggert

[larseggert]

For a bulk transfer, can this get us into a state where we're just pushing a remainder from transmit to transmit, causing memcpy churn? (We have a partial transmit, save a remainder, on next send try to send the remainder and the actual transmit, can't, and end up with another remainder?)

[thomaseizinger]

For a bulk transfer, can this get us into a state where we're just pushing a remainder from transmit to transmit, causing memcpy churn? (We have a partial transmit, save a remainder, on next send try to send the remainder and the actual transmit, can't, and end up with another remainder?)

In theory yes. I think that is still better than pretending to have sent the packets when instead they have been dropped. We'd have to gather some field-data to see how often that happens or we build in an algorithm that dynamically tunes the batch size?