Safer streaming decryption

[skeet70]

IronCoreLabs/tenant-security-client-java#25 brought up that the Java std library supports streaming AES-GCM decryption, but it's just for the interface. The implementation still buffers everything in memory before passing along the bytes after checking the auth tag. The code here is passing along the bytes as they're decrypted and then erroring if the auth tag is wrong, on the expectation the receiver will throw away/delete all the bytes it got because they've been tampered with. ironnode is writing the bytes to a tmpfile as they're decrypted, and then passing them along only if the auth tag is right.

We should make at least the two TSCs streaming behavior consistent, and probably ironnode too. Once chunking is supported we can safely do real, low memory, streaming. Until then, in all libraries, we should decide to either:

• do the safest thing and not pass along any bytes until we've confirmed the auth tag, with documentation disclaimers that the entire document will be buffered in memory. This is the easiest for the end user because they don't need to know or think about the authentication issues and can just call and use the bytes they get, but has the downside of not being able to decrypt large files (which is one of the common reasons to use streaming decryption).
• pass along bytes as we go and have the stream error if the auth tag doesn't check out. This would support large files and a lower memory footprint, but has the downside of the caller needing to understand (and us well document) that we're authenticating at the end and that they need to undo whatever they did with the bytes if they get an auth error from the stream.