⚠️ Add strongly typed EventNotifications

[xavdid-stripe]

]### Why?

As part of the Next-Gen Event Handling project, we're adding fully typed classes to represent all the thin events Event Notifications a user could receive. There are also helper methods that help with the event handling experience.

What?

• (see changelog below for user-facing changes)
• add tests
• add getMode helper for ApiMode
• fix doc typos

See Also

DEVSDK-2662

Changelog

We've overhauled how V2 Events are handled in the SDK! This approach should provide a lot more information at authoring and compile time, leading to more robust integrations. As part of this process, there are a number of changes to be aware of.

• Added matching EventNotification classes to every v2 Event. For example, there's now a V1BillingMeterErrorReportTriggeredEventNotification to match the existing V1BillingMeterErrorReportTriggeredEvent. Each notification class defines a fetchEvent() method to retrieve its corresponding event. For events with related objects, there's a fetchRelatedObject() method that performs the API call and casts the response to the correct type.
• ⚠️ Rename function StripeClient.parseThinEvent to StripeClient.parseEventNotification and remove the Stripe.ThinEvent class.
  • This function now returns a Stripe.V2.Core.EventNotification (which is the shared base class that all of the more specific Stripe.Events.*EventNotification classes share) instead of Stripe.ThinEvent. When applicable, these event notifications will have the relatedObject property and a fetchRelatedObject() function. They also have a fetchEvent() method to retrieve their corresponding Stripe.Event.*Event instance.
  • If you parse an event the SDK doesn't have types for (e.g. it's newer than the SDK you're using), you'll get an instance of Stripe.Events.UnknownEventNotification instead of a more specific type. It has both the relatedObject property and the fetchRelatedObject() function (but they may be/return null)

[jar-stripe]

left a few comments; nothing at all major but we should address them before merging.

[xavdid-stripe]

(ignore red CI; docker hub is having a problem so all tests are down. Everything besides compat was good before i merged master back into this and trigger the CI run.)