In version 17.3, the analytic mixin was introduced in budget.line model to allow to link a budget line to multiple analytic accounts belonging to different analytic plans. The issue is that we have not adapted the code in project profitability, to take those changes into account. A problematic situation could be the following:

1. We have a project where the account "X" is set to the main project plan (the first one) "Projects" BUT the account "X" actually belongs to the analytic plan "Departments" (yes, it's possible that there is a mismatch between the project plan and the analytic plan, especially after the 18.0 upgrade where "analytic_account_id" just became "account_id", no matter in which plan it was).

2. We have a budget line linked to the account "X" for the plan "Departments".

3. We want to display the budget lines in project profitability, but this line does not appear. That's because we currently only look for the budget lines belonging to the analytic plan "Projects" aka the main/first plan, that match the account "X" of the project. But as account "X" actually belongs to the analytic plan "Departments", no budget lines are found.

task-4901400
version-18.0

Forward-Port-Of: odoo/enterprise#88658

[FIX] account_accountant: refactor and optimize _try_auto_reconcile_statement_lines()
In big databases, this method called on large recordsets of statement lines would take too much time, or worse: timeout.
This is mainly because the 2 SQL queries are doing too complex searches and hence are badly optimized by the query planner.

To solve that,
* We search for reconciliable accounts outside the queries to avoid a join
* We add a trigram index on statement_line.payment_ref and only use ILIKE operations for reference matching so that it can be used
* Instead of using complex and costly regexp_split, we search for matches by splitting account_move_line.ref on ' - '
* We move some logic in python, amount matching, rather than in sql
* We don't try anymore to match on amounts found in the payment_ref

Additionnally,
* The algorithm now treats the statement lines with and without partner the same for reference matching, but lines without partner are just ignored for the amount matching, as it's way too dangerous
* Bug of with_prefetch, pre-loading the ids of a wrong object, has been fixed
* We revert the patch https://github.com/odoo-dev/enterprise/commit/da52bc70cd745f3e9f7a0539528c84aa47b98cc5 because it was only a temporary measure while the time was back to acceptable
* The test_matching_rules_with_empty_aml_ref, irrelevant, was removed

Benchmark
---------
Importing a csv file of 200 statement lines, on a database of 21M account.move.line, and thus triggering the culprit function, takes (hot timings):

| Before | After | Speed-up |
|--------|-------|----------|
| 185 s  |  52 s |   ~3.5x  |

see https://github.com/odoo/odoo/pull/218642

Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session.

Steps to reproduce:
-------------------
* Go in the setting and set up urban piper (no need for credentials) testing with random keys will do
* Go into the payment methods and take one of the urban piper one and assign it to a shop
* Open that shop
* Place an order and use the urban piper payment method
* Validate
* Try closing the session
> Observation: Nothing happen, we're now unable to select the menu. If doing
the same steps but in debug mode, a traceback is shown indicating a duplicate key in a t-foreach

Why the fix:
------------
The duplicate key is happening when rendering the closing popup because the function `get_closing_control_data()` was returning twice the information related to the urban piper payment method.

Even though urban piper wasn't build with the use case in mind we want to keep it possible. We avoid sending twice the urban piper methods if they were already computed in the super method.

opw-4874699

Forward-Port-Of: odoo/enterprise#90427
Forward-Port-Of: odoo/enterprise#88156