fix space accounting in the receive buffer

[Stebalien]

First, I've removed the atomics because they don't really give us much and are a bit misleading. We only use them to access the length taking a lock, but we can't actually set them without holding the lock.

Second, the receive buffer logic wasn't quite correct. The window size is len+cap, not len+cap+pending. When we copy data from the network, we add it to len, but then we remove the same amount from cap, so copying data from the network does not affect the window size.

The receive buffer looks like:

|            receive window (10)    |
|     data      | empty space       |
|< len (5)     >|< cap (5)         >|
                |< pending (4) ->|

As data is read, the buffer gets updated like so:

    |         receive window (8)     |
    |     data   | empty space       |
    |< len (3)  >|< cap (5)         >|
                |< pending (4) ->|

It can then grow as follows (given a "max" of 10):

    |         receive window (10)       |
    |     data   | empty space          |
    |< len (3)  >|< cap (7)            >|
                |< pending (4) ->|

By counting "pending" towards the window size, we wouldn't send a window update if:

1. The window was below half the maximum (should send an update).
2. We were about to read some data from the network (reserved).

This was causing the partial window update test to flake.

[willscott]

we didn't do great on naming this, since Cap in go terminology gets used for the allocated space (len+cap) of the object. the comment helps though.

[Stebalien]

Yeah. I tried making it work like go, but it wasn't much better.