ossl: Don't encryt/decrypt too much data for chacha20.

[jhb]

Summary

The loops for Chacha20 and Chacha20+Poly1305 which encrypted/decrypted
full blocks of data used the minimum of the input and output segment
lengths to determine the size of the next chunk ('todo') to pass to
Chacha20_ctr32(). However, the input and output segments could extend
past the end of the ciphertext region into the tag (e.g. if a "plain"
single mbuf contained an entire TLS record). If the length of the tag
plus the length of the last partial block together were at least as
large as a full Chacha20 block (64 bytes), then an extra block was
encrypted/decrypted overlapping with the tag. Fix this by also
capping the amount of data to encrypt/decrypt by the amount of
remaining data in the ciphertext region ('resid').

Reported by: gallatin
Sponsored by: Netflix

[jhb]

Drew had a panic in production where the relevant mbuf had a cipher text payload of 0x1b7 bytes in length. I was able to reproduce with a size of 112 (one full block plus enough of a partial block that the poly1305 hash equaled a second full block). I've tested this fix with both sizes. The following review for cryptocheck expands the sizes covered to handle this case, but it in a slightly more general way.