Add non-verified methods to managed handlers

[xavdid]

Why?

On the back of my work in DEVSDK-3085, we're adding support for non-verified webhook handing to the managed handlers. There were two key design stipulations:

1. It should be impossible to handle a webhook on the with-verification handler without supplying a signature header. As a result, we have to be very careful about overwriting/mixing our handle methods and if/when we call the signature verification methods.
2. The without-verification handler should feel like an implementation detail (where possible). Users should feel like they're interacting with "The" event notification handler

To that end, the main entrypoint for the non-verified handler is a new method on the client and a static method on the with-verification handler. The class definition and/or constructor for the non-verified handler is as private as possible.

Design wise, the exact implementation varied between languages:

• In cases where a child could shadow a parent method by name while changing the function signature incompatibly (python, ruby) I made the non-verified handler the base class and the verified one a child. They each have their respective handle methods and the amount of duplicated code is minimal
• In Go, I could shadow the handle method after embedding the with-verification handler inside the non-verification handler. It would have worked the other way too, but this was the least code change
• In cases where the language routes based on method arity (java, dotnet), I went with a "sibling" approach where all the handler methods are generated onto an private abstract base class and the with- and without- verification handlers are both children. That way they each have distinct handle methods and it's impossible for a caller to see the "wrong" one. If we had used inheritance, then the child would have the parent's handle signature exposed, which is confusing (even if we overrode it to always error)
• And in some languages (php, Typescript), function compatibility is enforced from parent to child, so we could remove or add the signature argument to handle. Instead, I took the same "sibling" approach described above so a caller only ever has the correct handle

What?

• Add StripeEventNotificationHandlerWithoutVerification class and associated constructors
• add tests
• TKTK

See Also

• TKTK