Accessing external resources in chrome can increase randomness in execution for multiple reasons:

- the external resource may temporary not be available
- the external resource may be faster-slower to load
- the external server could block some requests because of rate limiting
- the network may be unreachable.

Moreover, downloading fonts at every execution also slows down the tests

A possibility to solve the issue was to block the network on runbot, in the dockers. The main problem with this solution is that it wouldn't be the same behavior locally. It is also hard to adapt all versions at the same time.

This commit introduced another solution, using Fetch.enable in the chrome developers tools. This will allow to have a callback on every external request, allowing to enable/disable/give an alternate answer to the request.

All local request are allowed, all external request should be either
blocked or an alternative answer given.

This could be costly but at first glance it looks like it had no visible
negative impact on performances.

The first version was blocking all external requests, leading to a lot of failing tests, most of them already seen in nighties. It is hard to say since depending on when it happens it could create different error message, at least a few dozens of error related to this where found, maybe a few hundreds looking at the kind of patterns it can cause.  

Following this attempts a fix was to vendor all needed sources leading to ~130 cached url, with more than 100 fonts. This list was furthered reduced to have default fonts that would be returned reducing the load.

A test was made to return a 404 instead and it was actually enough, and it is the same for most requests (stripe, ayden, ...). Only a few of them needs a answer close to reality.

- The gooleapis css can be emty but not a 404 because it may make some of the css computation fail (website.backend_assets_all_wysiwyg.min.css) One of the failling test is TestCustomSnippet.test_01_run_tour

This final version returns a 404 for most resources.

A version returning 500 also works fine.

This pr could impact other cis (odoosh, other runbot) but the impact is expected to be slow wince only two tests needed to be adapted outside tests/common.py. It would be still possible to make Fetch.enable optional using an environment variable. 

Targeting 18.0 looks reasonable for a start, could be backported to 16.0 later

Note that this pr may make some random error more frequent, #207469 was needed to make this pr green. 
The assumption is that the speedup of the loading of some resources (or possible slowdown of local request) may change the timing of the execution revealing making some error more frequent.

**Steps to Reproduce:**
- Go to Sales
- Make a user-defined filter and make it the default filter
- Try to access the JSON link (/json/sales)
- You will see an error

**Issue:**
- When users apply default filters like 'My Quotations' or 'My Documents', Odoo saves 'uid' in the filter's domain to represent the logged-in user.
- However, when the system tries to process this filter, it fails because 'uid' is just a placeholder and not a valid value. This results in an **internal server error**, preventing users from applying these filters correctly.

**Cause:**
This issue is caused after this commit: https://github.com/odoo/odoo/pull/182196
- The domain string stored in 'ir.filters' includes 'uid' instead of the actual user ID.
- When Odoo('ast.literal_eval()') tries to evaluate the filter, it doesn’t know what 'uid' means, causing an error.

**Fix:**
- Replace 'uid' with `str(model.env.uid)` before evaluating the domain.
- This ensures 'ast.literal_eval()' processes a valid domain.

**Affected version:** 18.0~master
**opw**-4645608

Use case:

- Create an database with eCommerce (`website_sale`) (and for a country where PEPPOL is supported)

- Enable `Automatic Invoice` in General Settings.

- Configure everything for PEPPOL but do not register the company (Partner have their PEPPOL EAS and Endpoint correctly configured)

- Enable a card payment provider

- As a customer, buy something from the shop and paid using a card

=> When post-processing the customer payment (payment.transaction) we will automatically generate and send the invoice; and while trying to send the invoice we will crash with:

`ValueError: Expected singleton: account_edi_proxy_client.user()`

  The reason is that we try to send the invoice to both email and
PEPPOL while the company's registration on PEPPOL was not yet be done.

  This commit ensure we don't suggest sending by default on PEPPOL
if the company is not allowed to send on PEPPOL.

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

Before this commit _compute_parent_line_id make the assumption that a parent line can only be linked to once child: When the parent_line_id is set, it's remove from the pool of possible parent_line_id

Actually this is not the case, different upsell order can have a line that have the same parent.

Upsell order A can have line 1 with the same parent as the line 2 of Upsell order B.

Before this commit if the parent line of both order were computed at the same time one of them would end up without parent.

This situation is getting worse since odoo@42008de (saas-18.1) were all the parent_line_id are recomputed on every upsell order (even already confirmed one) as soon as line on the parent order are touched

The follow use case lead to duplicate line on the parent

A parent subscription A with 1 product Z
Create an upsell B with a line that upsell 1 product Z Create an upsell C with a line that upsell 1 product Z On both upsell the parent line is set properly

Confirm Upsell B, the parent line on Upsell C is set to false Confirm Upsell B, the parent subscription ends up with a two line for the product Z

After this commit,
parent_line_id are computed per order, so one order cannot have two lines with the same parent_line_id but two (or more) different order can have each one line with the same parent_line_id even if their parent_line_id are computed at the same time.

### Steps to reproduce:
- Create an invoice with a due date past for long time
- Accounting > Customers, click on the partner of the invoice
- In the page "Accounting" the "Follow-up Status" should be "In need of action"
- Click the gear to see the actions > "Process Follow-ups"
- The follow-up is send without any attachment

### Cause:
This [commit](https://github.com/odoo/enterprise/commit/cc759094a32e413cb1b71cbbe7be9dc85ded819f) moved the block of code responsible for getting the attachments from `_send_email` to `execute_followup`. 
The goal was to generate the attachments even if the "email" option is not selected in the send&print wizard. So basically, always generate the attachments.

But the method `execute_followup` is only called when processing the follow-ups manually, via the wizard. So the server action sent the follow-up without attachments.

### Solution:
Move the block of code from `execute_followup` to `execute_followup_partner` which is the method called in any case to send the follow-up report.
This way we always have attachments with the followup.

A lot of tests had to be adapted as they are now calling `export_to_pdf`. 
The test `test_send_followup_no_due_date` had the option `'manual_followup': True` but no `attachment_ids` which is never supposed to happen, it was crashing [here](https://github.com/odoo/enterprise/blob/2da6836520c4e7760e57062e3e97a22b744baacf/account_followup/models/res_partner.py#L278).

opw-4715486