Use readatleast instead of reimplementing it

[nightlyone]

use io.ReadAtLeast instead of reimplementing it

This also returns the correct error (io.UnexpectedEOF), if we didn't get what we want.

It made no difference to the callers -- which I audited down to packets.go -- where we convert any error from this path to driver.ErrBadConn so the propagation of this new error stops in packets.go.

Future enhancements can now differentiate between the EOF situation after we got what we want and before we could read a complete packet.

[julienschmidt]

Thank you for the proposal, but except for returning the right error this doesn't improve anything.

I think the following lines in io.ReadAtLeast can actually cause problems. We had problems with masked errors in the buffer code before:

if n >= min {
    err = nil
}

Moreover io.ReadAtLeast is not as optimized as our own reimplementation can be. Since these are are just a few lines of code, I think it is OK to reimplement it.

Future enhancements can now differentiate between the EOF situation after we got what we want and before we could read a complete packet.

No, there is no case where an expected EOF can happen. But you are right, the current code returns the wrong error, I therefore propose #269 which fixes the error and introduces some further optimizations instead.

[nightlyone]

I agree with the theoretically masked error issue. Maybe worth filing an issue at Go itself?

The history of this file shows, that re-implementing buffering is error prone. Errors in buffering code have a history of lots of bugs in many software, so I personally wouldn't do it.

On the other hand buffering code is a highly opinionated and fun field of play :-)