Fixes #4617

Short summary: we go down the following chain when we try to read data from containerd via grpc:

1. NewContentStore returns a content.Store implementation, specifically, proxyContentStore
2. When attempting to get a reader via proxyContentStore.ReaderAt returns a content.ReaderAt implementation, specifically remoteReaderAt
3. When remoteReaderAt attempts to ReadAt, it calls api/services/content/v1.ContentClient.Read() here
4. The protobuf-generated go code for v1.ContentClient.Read() creates a grpc.ClientConn.NewStream

The comments on NewStream explicitly state:

ctx is used for the lifetime of the stream

Yet we have the single context for the entire life of the connection. With a short content blob, it doesn't matter; with a larger one, you have leakages of hundreds, thousands or tens of thousands of goroutines (and whatever other resources, like memory) are attendant to them.

This creates a derived child context for each ReadAt(), and therefore each NewStream(), and then cancels the child context only as soon as the ReadAt() is done.

See the attached issue #4617 for much more detail. Short and simple test:

1. Run ctr content get for some large blob
2. While halfway through, do kill -USR1 <ctr_pid> or, if you don't mind killing it entirely, kill -ABRT <ctr_pid>
3. See thousands of goroutines in select state with grpc.newClientStream
4. Rebuild with this patch
5. Repeat
6. See exactly one goroutine in select state with grpc.newClientStream - it is fixed

As discussed with @dmcgowan