Run actual stripe api tests on ci

[arnav13081994]

This PR achieves the following:

1. Updated ci.yml to run tests using the Actual Stripe API injected through Github Secrets.

Note: This PR should only be merged after #1832 gets merged.

[arnav13081994]

@jleclanche I do not have enough access to be able to Create Github Secrets.

[jleclanche]

@arnav13081994 this isn't the right way to do it ... if you run into 429s the tests should know to retry

[arnav13081994]

@jleclanche That was my first approach to fixing this issue. The following complicates the implementation:

1. All existing network calls need to be refactored to go through this universal djstripe's internal HTTP interface. Lets call it DJSTRIPEHTTPCLIENT.
2. DJSTRIPEHTTPCLIENT must then handle stripe RateLimitError using exponential backoff up to a max number of retries.
3. So far everything is well and good till you realise that we can't retry stripe requests without an idempotency key for risk of creating multiple objects.

Therefore the only way we can handle this is by:

1. Generating idempotency keys for every request.
   1. Providing the users with a mechanism of accessing the key so that they can also retry the request.
   2. But can also choose to generate a new one if they wish to do so.
2. Updating the current code to pass idempotency key like stripe_account, api_key are passed around.
3. Create DJSTRIPEHTTPCLIENT interface with exponential backoff etc.

[jleclanche]

I mean, this retry strategy with idempotency key is something that should be in dj-stripe core. We have the tools for it. I think your tests are essentially showcasing the issue.

[arnav13081994]

I agree and was planning on adding DJSTRIPEHTTPCLIENT to the codebase anyway but this wait solution seems like a good enough fix (for now) just to be able to start adding tests using the stripe api. I can probably try to put together the DJSTRIPEHTTPCLIENT over the weekend but that would need to be very, very thoroughly tested as this would be a huge change because of potential duplicate objects getting created in production.

What do you think?

[jleclanche]

If it's just to land the tests then ok, but I worry about it severely increasing the run time of our CI.

[arnav13081994]

I see. Is there anyway we can review Github Actions usage? It seems I do not have enough access.

Please check it here

[jleclanche]

We aren't limited in usage but I want to keep it to a minimum anyway. It's wasteful in energy and it increases iteration time on PRs.