Docs for Tcl_CreateChannelHandler() state that the registered handler proc
will be called back with a mask value. "Mask is an integer mask indicating
which of the requested conditions actually exists for the channel; it will
contain ***a subset of the bits from the mask argument*** to
Tcl_CreateChannelHandler when the handler was created." (emhpasis added).

Tcl_NotifyChannel is not honoring this.  It passes a mask value that may
contain bits not in common with the mask argument to T_CCH().

This commit is a one-liner patch adding in the masking step to make things
behave as documented.  Thanks to apn for digging this out.  (In combination
with other questionable code, this led to a hang in test http-4.6 on Windows)

Tcl_NotifyChannel() has had this error in all of recorded Tcl history.
It's hard to imagine any code dependent on it though.  If any exists, it
can be revised to pass the mask value it truly needs to T_CCH() and end up
with code suitable both before and after this change.

If you concur, please merge to core-8-5-branch, and I'll take it from there.
Make test io-36.1.1 more portable.
Fix reviewed and accepted.
Test fix for likely cause of reported I/O slowdown.
In a DoRead() revision, it came to favor making every effort to fill
buffers, in preference to a more sensible goal of favoring avoiding calls
out to the driver if there's already enough data in the buffers to satisfy
the read operation.  Result is many more calls out to recv() than are
a good idea.  Ought to show up most glaringly when many Tcl_Read() calls
asking for small numbers of bytes (compared to buffer size) each, and that
matches the reported case.
Same results; simpler logic.
Correct performance regression in a series of short binary reads from a
socket.  Many thanks to Eric Boudaillier for the report and testing support.
merge 8.5;  fix notifier mask bug and Tcl_Read performance regression