[META] Add offsite payment methods support

Problem/Motivation

Few days ago I try to implement robokassa payment integration https://www.drupal.org/project/2681671/git-instructions (not finished yet)
I found that payment method plugins of payment 8.x are not supported the following:
1. Offsite redirect payment form (POST/GET).
2. IPN/interuction/rusult callback do not exist
3. IPN data validation method/callback do not exist
4. Static success/fail/panging routes do not exist (Not all payment systems support dynamic back urls and I think that this is bad behaviour to send back urls in payment form in most cases).
5. Payment->execute() method always set "pending" status before payment processing. That's OK for onsite payment methods but that's KO for offsite payment methods.

You must know that ~99% real online payment systems are required offsite redirect to process the payment because to get payment card info (card number, CVV, card owner) without redirect site must have PCI DSS cert.

I have searched the most generic workflow for offsite payment methods (check attached screanshort)
This workflow is used by all payment systems that I know. (Paypal, Paybox, PayU, Interkassa, Robokassa .... )
i.e. generic workflow the following:
1. Visitor submit payment on site.
2. Site create payment form according to order info and show "payment form" with sign and payment info according to payment system requirements.
3. User submit this form by himself or form will be autosubmited by js so payment process will start on payment system side.
4. Visitor fill info required by payment system and start the real payment process (auth+capture or auth with delayed capture)
5. When payment will be processed payment system will send IPN/interaction/result request to static site url configured in metchant account and we need to check if sign and payment data OK and change payment status. Only on IPN request we must change payment status. Many country specific payment systems ping IPN only on success payment result.
6. Anyway visitor will redirect to success/fail/panding (if status supported) page. In some cases we need fallback call IPN callback for correct process fail status here.

So now payment module not support most usable payment process in good order.

My investigation shows that now for cover this workflow in each payment method module we need to add
1. Payment redirect form controller
2. Controllers for static success / fail / panding pages. i.e. http://site.com/payment/complete (now http://site.com/payment/{payment_number}/complete)
3. Controller for static IPN url
4. IPN validator method
5. Redirect to site payment form must be implemented in getPaymentExecutionResult() method becouse $payment->execute() add redirect for executed payments only.
6. PaymentMethodBase->executePayment() always set pendding status before real execution by payment method class so IPN request can't call payment execute and must implement own logic in controller
7. IPN validator should be implemented as public although mutch better use protected for it
8. We can't call payment execute() twice becouse it always start process from the same status.

In general similar situation with payments availible in :
1. commerce 1.x (you can check my fixed implemlementations in https://www.drupal.org/project/commerce_robokassa and https://www.drupal.org/project/commerce_interkassa versions 2.x)
2. commerce 2.x seems payments not implemented yet
3. payment 7.x-1.x
3. payment 8.x-2.x

As result of this setuation on site payments created only on success processing or leave in pending state. So manager can't differentiate panding and fail payments so can't fully investigate payment issues with payment system support.

In all known for me payment method modules except commerce_robokassa 2.x and commerce_interkassa 2.x similar problems availible becouse error in example module.

Proposed resolution

We need to cover most usable offsite payment method workflow in 8.x.
1. Extend PaymentMethodBase with PaymentMethodBaseOffsite class for offsite payment methods and add Interface for it
2. in PaymentMethodBaseOffsite add following methods

• IpnValidator()
• IpnProcess()
• redirectForm()

3. Add routes for result pages like payment/{external_status} - (they may reditect to payment/{payment}/complete with additional logic there.
4. add External Status plugins and seperate execute methods for each status
5. Add seperate static route like /payment/ipn for IPN/interaction/result process.
6. Refactor payment->execute() method to react to current payment status. I think this method should call different payment method methods according to new payment status. (something like commerce next/prev in checkout)

Remaining tasks

• Discussing
• Patching

User interface changes

• none

API changes

• see Proposed resolution section

Data model changes

• none