Remove IO.read_exactly

[rgrinberg]

It's not being used anywhere as of #360.

Are there any good cases for keeping it? The main problem with this function
was how it sneaked in allocations of very large buffers into cohttp's code
base.

We could of course fix it by making sure it checks its argument and raises when
its above the maximum threshold. But in that case the user is just better off
using read. Since he will have to handle buffers larger than read_exactly
can handle using read anyway

@vbmithr Rather than fixing this function by raising when it try to raise large
buffers we can simply get rid of it.

cc @avsm @samoht

PS I don't consider this as a breaking change because IO is not officially part of the interface we expose.

[vbmithr]

Yeah, I would remove it. It would be nice to have a function that reads into a buffer instead of allocating, that would be more useful than this.

[vbmithr]

Actually, I would personally delete all IO functions that allocate buffers themselves. Reader has AFAIKS no one of them (apart from read_char, read_line, etc.). I don't like Lwt_io.read either.

And overall I'm 100% for deleting dead code, so I would say, go ahead :)

[rgrinberg]

I agree with that as well but just note that it can't be done very easily with current design. The problem is that we buffer things like request/response bodies. Unfortunately, this means that we must allocate more than one buffer for some requests. Changing Lwt_io.read into something like Lwt_io.read_into would simply move the buffer allocation from one place to another.

[vbmithr]

No but nevertheless it is more flexible to have functions that let you handle the allocation instead that function that allocate things for you.

[samoht]

fine with me