before this commit, a traceback was showing on creating product variant

steps to reproduce:
* click create button in product, traceback will be showing

after this commit, without any traceback product is created

traceback is introduced in: https://github.com/odoo/odoo/commit/758ced91f8cb220a003a49b01e047b507f8509d7

traceback details:

![2024-07-08_14-02](https://github.com/odoo/odoo/assets/99093808/fc3c5132-3e22-478f-8b93-2daf60877bc0)

super()._compute_display_name()
File "/data/build/enterprise/sale_renting/models/product_product.py", line 14, in _compute_display_name
super()._compute_display_name()
File "/data/build/odoo/addons/l10n_gcc_invoice/models/product.py", line 23, in _compute_display_name
product.display_name = re.sub(r'(\d)(\s)([\u0600-\u06FF])', repl, product.display_name)
File "/usr/lib/python3.10/re.py", line 209, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or bytes-like object

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

There is currently an issue with the `report_stock_quantity` SQL view. When there is only 1 `stock_warehouse` in a given database and `pg_stats` for `stock_warehouse` is up-to-date, the query plan for scanning the `all_sm` cte (the `existing_sm` cte is always inlined) becomes extremely bad. That's because postgres somehow expects only 1 row returned by the `all_sm` cte whereas in real databases it can be closer to 500 000. This makes postgres plan a Nested Loop Join that has very bad performances in large databases.

Another weird side-effect of this is the production vs staging (duplicate) on Odoo.sh. Because stagings and duplicates don't necessarily have up-to-date statistics, you can have the same query being very slow on the production database and very fast on a staging. That's because in the absence of statistics for the stock_warehouse table, postgres does not make any particular assumption on the number of rows returned by the `all_sm` cte and therefore produces a more efficient plan.

This commit tries to change that by introducing a new small CTE that simply does a LEFT JOIN between `stock_location` and `stock_warehouse`. Because this CTE is referenced twice in the `existing_sm` CTE, it will be materialized by postgres, i.e. evaluated first before being saved in memory for further usage. Thanks to that, postgres knows the expected number of rows of the CTE and can better plan the outer query's execution.

#### speedup

Customer database with 17 000 products, 700 000 stock.moves, 97 locations and 1 stock_warehouse. Doing a simple GROUP BY query on `report_stock_quantity`: 5min -> 1s

##### dalibo

To understand the dalibo, currently there is a workaround for this issue. If we add (and archive) a new `stock_warehouse` and then analyze the table, postgres plans an efficient plan. My guess here is that with only 1 record postgres skews the plan, probably because it tries to shortcut parts of the query execution. When there are 2 or more warehouses it cannot do that anymore and simply relies on correct statistics to plan the execution. Another possibility would be that statistics for tables with 
only 1 row are badly used by postgres. In any case, the point of the new CTE is to match the 2 or more warehouses case when
postgres plans the scanning of the `all_sm` CTE.

- [1 warehouse, base case](https://explain.dalibo.com/plan/a8fagdgd2d20ae48)
- [2 warehouses, base case](https://explain.dalibo.com/plan/2d38fb9ef6df495g)
- [1 warehouse, new CTE case](https://explain.dalibo.com/plan/92e41053c9g0ce8d)


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#169401