…orting

This commit introduces a significant change in the paradigm of how the
payment engine handles processing errors.

The previous mechanism relied on exceptions bubbling to signal
processing errors to the callers (payment form, web client, cron). This
approach posed two problems: it was necessary to catch and handle any
exception raised by the payment engine, and transactions were not
persisted if an error was encountered and the cursor rolled back.

The new approach consists of catching exceptions as soon as possible to
prevent them from discarding database changes, setting the transaction
to the 'error' state, and saving the error message on the transaction.
It allows tracking transactions whose processing failed, and simplifies
the handling of payment errors for applications integrating with online
payments (e.g., Subscriptions).

A number of collateral changes are made to enable the state-based
reporting and streamline the integration of new payment providers:

- A new `_send_api_request` util method is introduced on both the
  `payment.provider` and `payment.transaction` models to handle all API
  requests for the providers and centralize the management of processing
  errors. A series of specific hook methods are introduced to allow
  providers to configure the requests: `_build_request_url`,
  `_build_request_headers`, `_build_request_auth`,
  `_parse_response_error`, and `_parse_response_content`.
- The processing-oriented methods (`*_from_notification_data`) are
  replaced by a new set of core and hook methods to centralize all the
  common logic involving error management. The overrides are kept to a
  bare minimum, consisting of only the provider-specific handling of
  transactions.
- Provider-specific overrides of core `payment` methods are no longer
  required to call the `super()` method. This is made possible by moving
  the common logic previously living in those core methods into new,
  high-level business methods: `_charge_with_token`, `_capture`,
  `_void`, and `_refund`.
- Action methods related to payment operations (capture, etc.) now
  display a toaster notification with the operation's result.
- The capture and void payment operations now always create a child
  transaction to track the operation's progress, and save any error
  message on the child transaction rather than the source one.
- Provider names are removed from the log messages and from displayed
  errors.
- A new `get_payment_logger` util method is introduced to configure
  the logger of a payment provider and automatically mask sensitive
  data (e.g., secret keys) from logs.

task-3648413

closes #209685

Related: odoo/enterprise#87325
Related: odoo/documentation#13888
Signed-off-by: Antoine Vandevenne (anv) <[email protected]>
Co-authored-by: Antoine Vandevenne (anv) <[email protected]>

task-3648413

closes #13888

Related: odoo/odoo#209685
Related: odoo/enterprise#87325
Signed-off-by: Antoine Vandevenne (anv) <[email protected]>