`std::io::Empty` that is never read from

What it does

If Empty is constructed yet its implementations of Read/BufRead are never required, we should suggest Sink instead which conveys this purpose better.

We also need to make sure some access does not require a trait outside of std that Sink doesn't implement.

Advantage

• This restricts it from being read from in the future, if that's undesirable.

Drawbacks

• This restricts it from being read from in the future, if that's desirable.

Example

use std::io::{prelude::*, empty};

fn b<T: Read>(t: &T) {}

fn a() {
    let mut empty_unused = empty();
    empty_unused.write(&[0]);

    let mut empty_used1 = empty();
    empty_used1.write(&[0]);
    empty_used1.read(&mut []);
    
    let mut empty_used2 = empty();
    b(&empty_used2);
}

Could be written as:

use std::io::{prelude::*, empty, sink};

fn b<T: Read>(t: &T) {}

fn a() {
    let mut empty_unused = sink();
    empty_unused.write(&[0]);

    let mut empty_used1 = empty();
    empty_used1.write(&[0]);
    empty_used1.read(&mut []);
    
    let mut empty_used2 = empty();
    b(&empty_used2);
}

Start at the std::io::empty and std::io::sink entry points, and review how Empty implements Read and BufRead while Sink does not. Check the examples for write-only use, explicit reads, and generic Read access, including whether external traits affect the distinction. Done means the proposed lint handles these cases without restricting intended future reads.