feat: Allow async subscription handlers

[oliversalzburg]

I understand (and appreciate) that no breaking changes should be introduced into v1, as you've explained to me in #470. I just wanted to propose an actual change so you can assess what I'm suggesting.

I don't see this change conflicting with any existing subscription code, regardless of if graphql-subscriptions or a drop-in-replacement is being used.

The existing ResolverFn type from graphql-subscriptions is only relevant in their withFilter utility, which is not impacted by this change and continues to behave exactly as advertised.

Enabling async subscription handling would open up a lot of use cases in validating a subscription request, which currently has to be deferred into the handling of events in the subscription (like through the async filter method when using withFilter) when the subscription was already accepted.

Fixes #470

[codecov[bot]]

Codecov Report

Merging #955 (94d300c) into master (9d0491c) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #955   +/-   ##
=======================================
  Coverage   96.02%   96.02%           
=======================================
  Files          79       79           
  Lines        1687     1687           
  Branches      356      356           
=======================================
  Hits         1620     1620           
  Misses         66       66           
  Partials        1        1           

Impacted Files	Coverage Δ
src/decorators/Subscription.ts	100.00% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 9d0491c...94d300c. Read the comment docs.