Payments flow adaptation for lazy payments

[Tiago-Salles]

Context

The payment flow on our Open edX ecommerce instance currently checks asynchronous payments (MB references and MBWAY) synchronously, right after the user clicks Continuar on PayGate. Because the upstream payment is not yet confirmed at that point, handle_processor_response raises GatewayError ("PayGate couldn't double check if basket has been payed") and the user is shown the misleading message "You have not been charged." — even when, in many cases, the payment will be successfully confirmed by PayGate a few seconds/minutes later.

We do not want to introduce a background queue. The chosen solution is to defer the payment confirmation to the moment the user opens the Order History page, where each row will lazily consult the payment processor and update its status (and create the Order in place if the payment was confirmed).

This PR introduces the backend pieces of that lazy resolution in nau_extensions. The MFE (frontend-app-ecommerce) consumes these endpoints and the ecommerce-plugin-paygate redirects the user to the new Thank-You page; those changes ship in their own PRs.

What this PR adds

• BasketPaymentStatusView — GET /payment/nau_extensions/basket-payment-status/?order_number=…
  • Returns the current payment status of a single basket: paid, pending or failed.
  • If an Order already exists for the basket → returns paid immediately, without hitting PayGate.
  • If the basket has no PayGate PaymentProcessorResponse yet → returns pending without hitting PayGate (nothing to confirm).
  • Otherwise loads the PayGate processor via get_processor_class_by_name("paygate") and calls handle_payment + create_order + handle_post_order using a tiny EdxOrderPlacementMixin adapter (_LazyOrderPlacement). On GatewayError the response is pending. On other PaymentError or order-creation failures the response is failed.
  • Restricted to the basket owner (or staff users).
• PendingBasketsListView — GET /payment/nau_extensions/pending-baskets/
  • Lists the authenticated user's baskets that have at least one PayGate attempt but no Order yet, so the Order History page can show in-flight asynchronous payments alongside the standard /api/v2/orders/ results.
• Internal helpers _serialize_basket and _build_course_url to produce the JSON payload consumed by the MFE (including a best-effort LMS course URL used by the new "Go to course" action button).

What this PR changes

• views.py — new imports (GatewayError, PaymentError, Response, EdxOrderPlacementMixin, get_processor_class_by_name, PaymentProcessorResponse, OrderNumberGenerator, django_settings) and the two new API views described above.
• urls.py — registered two new routes:
  • basket-payment-status/ → basket_payment_status
  • pending-baskets/ → pending_baskets

Related PRs

• ecommerce-plugin-paygate: Payments flow adaptation for lazy payments ecommerce-plugin-paygate#27
• frontend-app-ecommerce: Payments flow adaptation for lazy payments frontend-app-ecommerce#3

Related to: https://github.com/fccn/nau-technical/issues/923