Better feature independence

[thomasmost]

Is your feature request related to a problem? Please describe.

I'm always frustrated that async-stripe (a huge Rust library) is nicely broken down into features but that it does not compile with sensible subsets of those features.

For example: I build an app that receives webhook events for invoice events and ONLY invoice events.

The feature set I'd expect would be:

async-stripe = { version = "0.39.1", default-features = false, features = ["runtime-tokio-hyper", "billing", "webhook-events"] }

billing gives access to the full invoice object. webhook-events gives access to webhook event verification and deserialization. But this does not compile because of a dependency on CheckoutSessionItem

11 |     Account, Application, CheckoutSessionItem, ConnectAccountReference, Currency, Customer,
   |                           ^^^^^^^^^^^^^^^^^^^
   |                           |
   |                           no `CheckoutSessionItem` in `resources`
   |                           help: a similar name exists in the module: `CheckoutSession`

Okay, let's add checkout:

async-stripe = { version = "0.39.1", default-features = false, features = ["runtime-tokio-hyper", "billing", "checkout", "webhook-events"] }

This fails due to a missing AccountCapabilities

428 |     AccountCapabilities(AccountCapabilities),
    |                         ^^^^^^^^^^^^^^^^^^^ not found in this scope
    |

Okay, let's add connect:

async-stripe = { version = "0.39.1", default-features = false, features = ["runtime-tokio-hyper", "billing", "checkout", "connect", "webhook-events"] }

Finally, this works.

Describe the solution you'd like

It seems like either the invoice feature should correctly include checking and connect as dependency features, or an effort should be made to toggle on the required elements of those downstream features.

I recognize that the latter is a big project, especially applied across the crate. Probably the "best" (and biggest) solution would be to have some automated compile testing of feature independence, ensuring that all valid feature combinations compile, but I know that's a tall order for an open-source project.

Still, incrementally moving in that direction seems like the right path forward.

Describe alternatives you've considered

Like I alluded to above, potentially an interim solution would be to simply add the required dependency features to invoice, at least for this case, and create a 'tech debt' cleanup task (maybe good for first-time contributors?) to try and disentangle them.

Additional context

Thank you for the excellent library! Overall I am very appreciative and grateful of the work you've done to maintain this tool.