Fix pre-auth behavior

[bpcreech]

Before this change we were erroneously marking pre-auth'd charges as status=pending, when they're actually status=succeeded. We were (accidentally) working around this incorrect behavior in pre-auth'd PaymentIntents.

To get this right we have to actually split the _trigger_payment method into two: a check for payment authorization (which we do on construction even for Charges created with capture=false), and a separate routine to actually capture the charge (which we do on construction for non-pre-auth'd charges, and on _api_capture for pre-auth'd charges). We then adjust the PaymentIntent wrapper to fit.

This also fixes a tiny mistake in the Charge refund test; it was asserting the wrong variable.

[bpcreech]

Actually sorry for the spam... there's still a flaw in this, for PaymentIntents we shouldn't check authorization until confirm. (So we need to not return a 402 on a PaymentIntent creation if confirm=false.)

Not sure if this PR makes that any worse, gotta think about it. Will consider and fix.

[bpcreech]

Actually sorry for the spam... there's still a flaw in this, for PaymentIntents we shouldn't check authorization until confirm. (So we need to not return a 402 on a PaymentIntent creation if confirm=false.)

Not sure if this PR makes that any worse, gotta think about it. Will consider and fix.

Actually this was working fine, what a pleasant surprise! :) I added a more elaborate test to verify it.

This should be good to review now

[bpcreech]

@adrienverge this one's ready for review if you want! We're using it at Via now (in an internal fork I want to get rid of :) ).

[adrienverge]

Sure! We'll look at it as soon as we have some time to review.

Good it to merge local edits upstream 👍 and by the way, do you plan to propose other ones? If it's the case, it's easier for us to test them all at once.