"Register after Checkout" Pane causes payment method reuse to fail

Corrected files paths.

We should also update the existing payment methods (mark relevant ones as non-reusable).

There is a possible alternative, not retroactive but proactive. Using the PaymentMethodCreateEvent from #3191993: Add event to allow customising payment method and customer creation allows a user to be created early in the process, before the customer and payment method are registered at Stripe. That user can be set as the payment method owner.

We are using this to provide the appearance of a fully anonymous checkout (no post-checkout registration), with re-usable payment methods if required. We create the user with a "pending" role to allow us to clean up if we get a lot of old uncompleted transactions/users. I can provide the code we are using for the event subscriber if anyone wants it. The whole thing could be provided by a separate module, with a cron cleanup to remove "pending" users older than a given threshold (we haven't needed that yet).

You'd still have to handle getting the user to "activate" their account, either via sending an email or by logging them in and asking them to reset their password or such. So it's not a solution for this issue, it's an alternative.

I've submitted an MR with a solution to this issue, which makes sure customer ID's are associated with payment methods that we are saving, then retains them and assigns them to the User that gets created by Commerce.

I'm attaching a patch of the current MR for convenience.

Discovered an issue with the latest solution, which is that a payment intent can't use a payment with a different customer ID. You can see this issue emerge if you select saved payment method associated with a different customer ID (one using the field added in this patch), then go back to change payment to a different or new payment method.

This is feeling like a generally bad approach to solving this problem. Instead, we should probably be smart about associating the new user with the customer record in Stripe.

However, here's a workaround which refreshes the payment intent.

Updated patch & PR to prevent overwriting of a user's existing customer ID. This commit seems relevant beyond this issue's specific problems, as it's certainly possible for a user to have a customer ID, then make an anonymous purchase using their email address, which will then break their existing saved cards without a fix like this.

Re-rolled patch #7 against the head of 8.x.1-x and created MR!101.

An enhancement has been added to assign the payment method when the customer has orders assigned to them. (Note: this also handles other scenarios, besides the "Register after Checkout" pane, such as checkout flow with create account for guest user or checkout flow with sign to existing user options enabled.)

This allows the payment method to properly be reusable.

Some notes:

1. This works for the Stripe Payment Element. If needed for Card Element, please create a separate issue to port similar logic, as it would require some refactoring in the Stripe.php class.

2. If backfill is needed, the database update in this thread might work on smaller sites, but not for larger sites with 100k/millions of records. A more targeted and performant query would be needed, along with the ability to defer/skip this revision, to be performed offline. A drush command might be a better option. That should also be a separate issue.

Reroll of my previous patch against the latest version. However, I don't like this solution. Saving a card for an anonymous user is not desirable.