Fix issue of potentially dropped messages in subscription

[jinhong-]

Fixed and refactored code to utilize async APIs, without using Task.Wait(), which potentially creates deadlocks. I have tested this to work in my project

[pekkah]

I think you still need to handle the case of SendAsync returning false. Trying again would be good or allowing user to specify what to do.

[jinhong-]

@pekkah Hmmm i am not sure if SendAsync actually returns a boolean as seen below:

server/src/Transports.Subscriptions.Abstractions/IWriterPipeline.cs

Line 27 in b028d3d

Task SendAsync(OperationMessage message);

I understand that underlying it is using ActionBlock.SendAsync, which provides a boolean return value. However upon reading the documentations and examples, there are plenty of results that point to the fact that it should not return false unless the block completes or fails
Question then now is if we want allow user to specify what to do, what would be the best way to do this? Here's what i am thinking:

On the event of a failure (SendAsync returns false):

1. Log failure
2. Terminate Subscription

Retries could be possible, however that would require passing in some sort of configuration from the root 3 levels into the Subscriptions class if we do not want to hard code the retry count

[jinhong-]

I made a small tweak to help with handling errors and terminating the subscription

[jinhong-]

@pekkah Are you able to take a look at the change and see if there are any more changes required?

[Shane32]

These changes should not be necessary in version 7 of GraphQL.Server