Apparently, although we tend to add the type of spec file some RSpec
methods are not working without it. We're getting:
```
NoMethodError:
undefined method `helper' for RSpec::ExampleGroups::SpreeSharedOrderDetailsHtmlHaml:Class
```
```
NameError:
undefined local variable or method `controller' for #<RSpec::ExampleGroups::SpreeAdminUsersController::AuthorizeAdmin:0x00007fa8b32addf8>
# ./spec/controllers/spree/admin/users_controller_spec.rb:10:in `block (3 levels) in <top (required)>'
```
It needs more investigation but another day.
Spec files individually include the module and we specify the type of
spec in each RSpec's describe so none of this settings are needed. They
are just Spree's legacy I bet.
In this particular case, the user confirmations controller is redirecting to the reset password page but it doesnt know what is the raw reset_password_token
So we regenerate the reset password token so that it can know what's the raw value for the redirect
The method User#regenerate_reset_password_token is a proxy to the protected method in Devise::Recoverable
The original payment may not be valid because its credit card may be
expired. Stripe gives this as a valid scenario returning a success and
we should do too.
When creating the credit payment we end up validating all sources in
a chain as follows.
```
Payment being persisted -> source payment -> original credit card.
```
The source payment was valid when created (It would not be persisted
otherwise) but its source card may now be expired, and that's legit.
There was also an issue with the `#invalidate_old_payments` callback. It
was causing the original payment to be validated again and thus the
credit payment failed to be persisted due to the original credit card
being expired. Switching this callback to use `#update_column` skips
validations and so we don't validate the source payment. We only care
about the state there, so it should be fine.
Given the importance of this code, it doesn't bring me much confidence.
Apparently, this specs where using a non-existent state by mistake and
this went unnoticed because the payment creation was failing silently in
payment/processing.rb.
This unearthed the fact that our `#ensure_correct_adjustment` needs the
order to be persisted to succeed.
