Steps to reproduce [17.1]:

- Add a property field to a job application in the backend.
- Go to the linked website job application form (in edit mode).
- The property field is inaccessible.

To be able to access the new property field in the application form, the
`job_id` value of the related job record needs to be specified by
default. Unfortunately, these values are removed before accessing "edit"
mode:

Starting from [1], a fix was added to clear default values coming from
`data-for` attributes when the form is edited (at `cleanForSave()`) to
prevent saving it with changed default values.

Since the code from [1] can also remove default values set by the user,
a new fix (see [2]) updated this implementation to ensure that only
values from auto-fill and data-for fields will be removed (this time,
when the form public widget is destroyed [3]).

The behaviour from [3] will always unlink the `data-for` values in edit
mode, and as a consequence, the related property fields won't be
correctly retrieved.

The goal of this commit is to fix this behaviour by excluding `data-for`
values from the reset in [3]. An extra check will be added to be sure
the form won't be saved with updated default values if it already has
`data-for` ones [4].

Important: The diff from [5] made the `email_to` field as an exception
for the data-for/prefill priority system and only used the `data-for`
value if nothing has been configured by the user (it also used the
`data-for` value if what was configured by the user is the dummy default
email: `info@yourcompany.example.com`). That's why we need to
exceptionally allow saving the default value added by the user in the
check from [4] to preserve the same behavior.

Following [6], The `email_to` value won't be kept in edit mode to
prevent breaking its dynamic behavior.

[1]: https://github.com/odoo/odoo/commit/b637a5e32f767b62736241042f88fa0cecf9f10b
[2]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544
[5]: https://github.com/odoo/odoo/commit/a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b
[6]: https://github.com/odoo/odoo/commit/6658d61e304c9dfd8e512648c4a001dcaac44bc1

task-3922573

Forward-Port-Of: odoo/odoo#204027
Forward-Port-Of: odoo/odoo#166565

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.

Forward-Port-Of: odoo/odoo#207157

There was an issue in the `PropertyDefinition:state.propertyDefinition`,
which could sometimes not be updated properly, resulting in a traceback after
multiple property definition changes.

### How to reproduce:
- Open a CRM Lead form view and add a property of type `tags`.
- Save and fully reload the form view.
- Change the property type to `separator`
- Change the property name to another value.
- Click outside the popover to close it.
=> Traceback
```
Cannot read properties of undefined (reading 'type')
at  PropertiesField.onPropertyDefinitionChange
```

### Technical explanation:
The `propertyDefinition` argument given to `onChange` props of
`PropertyDefinition` component is expected to be modified in place, since it is
used as the `propertyDefinition` state value.
`pick` function creates a shallow copy, therefore using it on
`propertyDefinition` in `PropertiesField:onPropertyDefinitionChange` and
applying changes on that copy (i.e. in `_regeneratePropertyName`) will prevent
these changes to be registered in the
`PropertyDefinition:state.propertyDefinition`, resulting in inconsistent values
with `PropertyField:propertyList`, which would manifest at the next definition
change, since `_getPropertyIndex` would not be able to find the index of the
now obsolete `propertyDefinition`.

task-4743860

Forward-Port-Of: odoo/odoo#206977
Forward-Port-Of: odoo/odoo#206871

Similar to: https://github.com/odoo/odoo/pull/184830

We've recently introduced a new operator: “is within” in the domain
selector, which can be used to find out whether a date is within a
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.

https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/web/static/src/core/py_js/py_builtin.js#L77-L79

However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s

In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:

`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.

This commit handles:
- website/model_page.py:
-
https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L13-L18


https://github.com/odoo/odoo/blob/2fed354787b6190ee8bca91dc49746fcd0631dd8/addons/website/controllers/model_page.py#L47-L57

The enterprise commit (https://github.com/odoo/enterprise/pull/82564)
handles two other cases:

- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2

- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`

In all three cases, the problem is the same: the problem is not only
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:

- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in et la the python server

- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)

- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`

- For the moment, the values we use are the same as those used by
`is_within`, i.e.:
-- context_today()
-- relative_delta()
-- datetime

opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091

Forward-Port-Of: odoo/odoo#206708
Forward-Port-Of: odoo/odoo#204172

### Steps to reproduce:
- Accounting dashboard
- Click on the three dots of the "Bank" card
- Click "import file"
- Try importing a CAMT file with the namespace "camt"
- Traceback

Other issue:
- Try importing a CAMT file with a custom Code in `ns:Domn/ns:Cd` (example: "IC1")
- Traceback

### Cause:
Namespaces can be used in CAMT files but the way Odoo handled them was incorrect. We were creating a dictionary using `root.nsmap`. It only worked when the file didn't have a namespace key because if the key was different from 'ns' the `findall` didn't work.

Second issue: Some banks use their own codes in the CAMT files. The specification has numerous codes which Odoo added in a dictionary, and it reads from this dictionary to get a description. When there is a custom code, Odoo tries to read a key which doesn't exist explaining the traceback.

### Solution:
- Change the way namespace is computed using the tag.

- If the code is not in the dictionary, we take the custom code.

opw-4553152

Forward-Port-Of: odoo/enterprise#82888

Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete.

Steps to reproduce:
-------------------
* Install fedex
* In operation types, select Delivery Orders then hardware
* In print on validation, enable Carrier Labels and Export Documents
* In the shipping methods, select fedex international
* Change Label format to ZPL11
* Connect the database to an iot box
* Set up the shipping labels to be send on zebra printer
* Set up commercial invoice (/invoice) to be sent to another printer
* Create a sale order, using fedex international as shipping
* Confirm the SO
* Select the delivery
* Validate the delivery
> Observation: Nothing prints, jobs are sent to CUPS bu not printing

Why the fix:
------------
https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_fedex_rest/models/delivery_fedex.py#L192-L196

As show, when sending the shipping, if the invoice is generated, it gets added to the attachements. The function `message_post` will post all attachments in the same chatter message.

In `delivery_iot` the `message_post` function is overridden to allow sending the printing jobs to the iot.

https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L33-L46

Here, `attachments_names` will both contain `Label` and `ShippingDoc`. Since we enter the first if condition, the report is related to the shipping labels. Then we send the data related to all attachments to the device linked to the shipping labels, aka the zebra printer. Since the other attachment is of type PDF, the zebraprinter does not know what to do with it and ends up printing nothing.

Since we can have multiple different attachment, the if/elseif condition does not make sense. By breaking it in two if, we can send both reports separately, while still keeping all attachments in the same chatter message.

opw-4546715

Forward-Port-Of: odoo/enterprise#83481
Forward-Port-Of: odoo/enterprise#82094

Similar to: https://github.com/odoo/odoo/pull/184830

We've recently introduced a new operator: “is within” in the domain 
selector, which can be used to find out whether a date is within a 
dynamic range (e.g. within a month, within 4 days, within 3 weeks, etc.).
To works, this domain needs dynamic elements, such as `context_today`,
which is defined in `py_builtin.js` and dynamically retrieves the
current date.

https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/core/py_js/py_builtin.js#L77-L79

However, the problem isn't limited to this operator in the selector
domain, as it's only been available since 18.0, and this pr target is
17.0.s

In fact, it is possible in certain cases to use these fields via debug
mode, and there are several cases where `uid`, `user`, etc. are used.
There is therefore an inconsistency where users see the use of these
variables in these cases and when they try to use them elsewhere with,
for example, a field of this style:

`("date", "=", context_today())`, they get a traceback.
This happens mainly because, in Python, the domain is evaluated via 
`literal_eval`, and since it contains variables that are designed for
the web, it causes a traceback because this function expects to receive
only a correctly formatted string, with no context and no variables.

The community commit (https://github.com/odoo/odoo/pull/204172) handles:
- website/model_page.py:
https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L13-L18

https://github.com/odoo/odoo/blob/17.0/addons/website/controllers/model_page.py#L47-L50

This commit 
handles two other cases: 

- web_studio/approval:
Here in this case there are several calls to literal_eval on domains
received from the web, notably to create and check its approval spec.
a function has been used to avoid rewriting the same thing several times
in the file.2

- marketing_automation/activity:
Here too, several calls are made to this file, as in the case of
approval, a function has been created to replace all calls to
`literal_eval`

In all three cases, the problem is the same: the problem is not only 
present in `is_within` but in the fact that python has no way of
understanding the domain received from the web, so the same fix has been
applied everywhere:

- First, `to_utc()` is removed from the domain, since it's purely
client-side and this notion doesn't exist in the python server

- We replace the `literal_eval` call with `safe_eval`, which will do
more than just transform a string containing only a literal value of
type X into type X (e.g. tuple, string, number, array, etc.)

- `safe_eval` can therefore either evaluate expressions or execute
statements. In our case, what we really want is to evaluate just a
string like literal_eval with just one more context, and to be able to
define local or global values, such as defining `context_today()`

- For the moment, the values we use are the same as those used by 
`is_within`, i.e.:
  - context_today()
  - relative_delta()
  - datetime
  - time


opw-4551335
opw-4672902
opw-4678894
opw-4669315
opw-4577091

community: https://github.com/odoo/odoo/pull/204172

Forward-Port-Of: odoo/enterprise#83738
Forward-Port-Of: odoo/enterprise#82564