Usage of tokio::fs/io in client stream handler function seems to prohibit client stream error propagation

## Bug Report

### Version

```
tokio = { version = "1.6.1", features = ["macros", "rt-multi-thread", "io-std", "io-util", "fs", "time"] }
tokio-stream = "0.1.6"
tonic = { version = "0.4.3", features = ["tls"] }
prost = "0.7.0"
prost-types = "0.7.0"
```

### Platform

macOS 11.5.1 amd64

### Description

I have a function handling the parsing and writing of binary assets contained with proto messages to disk, called from the client stream handler message loop. In the asset writing function I make use of tokio::fs/io for creating directories, writing and flushing to disk.

However, when the stream was dropped by the client, instead of the `stream.message().await` returning an `Err` the gRPC function handler seemed to simply stop as far as I could tell. No panics, just the following line posted to stdout:

`DEBUG hyper::proto::h2::server] stream error: connection error: broken pipe`

When printing to stdout during the asset write function the execution always stopped around awaiting a tokio::fs/io call. I could not find anything or produce any theory what is going on, I ultimately did manage to resolve it by switching to the regular std::fs/io calls.

When the stream drops now, the following log message gets printed and I do actually get an Err on the `stream.message().await` function.

`[2021-08-18T19:25:59Z DEBUG tonic::codec::decode] decoder inner stream error: Status { code: Unknown, message: "h2 protocol error: broken pipe" } `

Sorry if this report is a bit vague but after several days I was not able to get any insight into why this is happening, hopefully this rings a bell somewhere.