Cancel safety audit

[k0nserv]

When writing futures that are likely to run in race with others using e.g. tokio::select! it's important to consider cancel safety.

A typical pattern that isn't cancel safe is

async fn read_parsed<T>() -> Result<T> 
    where T: TryFrom<Vec<u8>>
{
    let mut buf = vec![0; 100];
    let n = read_io(&mut buf).await?;
    buf.truncate(n);
    
    let parsed = T::try_from(buf)?;
    
    // If the future is dropped here the data has still been read from some I/O device
    // but the buffer and parsed result are deallocated and never returned to the caller.
    some_other_thing(&parsed).await?;
    
    Ok(parsed)
}

We should audit the codebase for patterns like this and either: make the futures cancel safe or at least document the fact that they aren't.

I've discovered three cases so far:

• GeneratorStream::read Fixed
• interceptor::report::receiver::receiver_stream ::Receiverstream::read Fixed
• interceptor::twcc::receiver::receiver_stream ::ReceiverStream::read

We might able to utilise Codec from tokio-utils in some instances to help with this.

Crates

Here's a list of all the crates and their audit status for cancel saftey

• rtp
• rtcp
• sctp
• data
• ice
• dtls
• mdns
• media
• interceptor
• webrtc
• sdp
• stun
• turn
• util

More reading about cancel safety

• https://blog.yoshuawuyts.com/async-cancellation-1/#cancelling-futures
• http://smallcultfollowing.com/babysteps/blog/2022/06/13/async-cancellation-a-case-study-of-pub-sub-in-mini-redis/

[k0nserv]

This PR is a first step in this, it fixes two of the above identified issues