Fix TROVE-2019-001 (KIST can write above outbuf highwater mark)

[nickm]

From the fix in be84ed1a64ed7ce810bd3924fa96c2588b491ef5:

    KIST works by computing how much should be allowed to write to the kernel for
    a given socket, and then it writes that amount to the outbuf.
    
    The problem is that it could be possible that the outbuf already has lots of
    data in it from a previous scheduling round (because the kernel is full/busy
    and Tor was not able to flush the outbuf yet). KIST ignores that the outbuf
    has been filling (is above its "highwater") and writes more anyway. The end
    result is that the outbuf length would exceed INT_MAX, hence causing an
    assertion error and a corresponding "Bug()" message to get printed to the
    logs.
    
    This commit makes it for KIST to take into account the outbuf length when
    computing the available space.

[nickm]

Marking tickets as 040-must based on triage with dgoulet.

[nickm]

(the patch is on the network team security encrypted ML)

[nickm]

For what it's worth, we've only been able to actually make this crash occur in a pretty nonstandard testing environment, and only then against clients. But it's entirely possible that there's some way to exploit this in the wild that we're missing. Out of caution, we're giving this issue medium severity, and putting out patches: better safe than sorry.