Fix Crypto API stuck on long streams

[antontroshin]

Description

The "Receive" was not called as the "Send" got stuck after about ~400kb of data was sent, it seems like a buffer was full, but since "Receive" wasn't called, the buffers weren't draining.
Once the "Send" task is not awaited, "Receive" is called and starts pulling data.
As long as "Send" is somehow being chained together with "Receive" (using Task.WhenAll, or .ContinueWith, etc), the "Receive" task is not starting.
The only way I was able to complete both was to disconnect them.
Ran 1000 iterations of EncryptAsync + DecryptAsync:
Using 6Mb file, total data processed ~12Gb (Encrypt 6Gb + Decrypt 6Gb)
No increase in memory was observed for daprd and tester app.
All went successful, the "Send" task was completed and cleaned.

Nevertheless, knowing that this is not a good practice when working with Tasks, would like to receive an opinion on this change or maybe an idea why this might happen with tasks.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #[issue number]

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[WhitWaldo]

Thank you for your report!

While the removal of Task.WhenAll would remove the blocking behavior you're experiencing, wouldn't you expect the operation to be blocking so that when the task returns, you can rely on an expectation that the full plaintext value was received and the full ciphertext value returned or vice versa (where in theory the encryption service should continue to operate as long as there's an inbound stream)?

By not awaiting the outbound side of the operation, exceptions wouldn't be propagated and any resources that would have been released because of the exception wouldn't release. Further, the use of Task.WhenAll means that when the provided cancellation token flags for cancellation, both operations can be cancelled. Here, if the receive operation completes (theoretically shouldn't happen) or is canceled first (could happen), the outbound side may not be properly canceled.

I think this solution needs more testing before we just merge it in. I'll get a larger file added for testing purposes and see if I can't reproduce your experience.