During an onchange, fields read from database are validated again. This causes an infinite loop with HTML fields since Odoo 16 because we're revalidating a value we're reading from the database, which triggers a sanitize check, which fetches the original value, etc etc.

Even if the functional bug only appears in 16.0 and above, the root cause is also present in 15.0 so this commit targets 15.0

steps to reproduce (in 16 or next versions):

- Change Marc Demos's access rights Website = Restricted Editor
- Bypass HTML Field Sanitize = Off
- Inventory / Products / Product Variants
- Studio on the Sales tab and add website_description under Website Sequence
- Go to product [E-COM07] Large Cabinet and fill in the newly added website description
- Log out and log in as marc demo
- Navigate back to [E-COM07] Large Cabinet product variant and try to re-order the vendors on the purchase tab
- Error

before this commit:
Error (infinite loop) during onchange

```
File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 6489, in onchange
    record[parent_name]._update_cache({name: record[name]})
  File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5310, in _update_cache
    value = field.convert_to_cache(value, self, validate)
  File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
    return self._convert(value, record, validate)
  File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
    original_value = record[self.name]
  File "/home/nda/dev/odoo/16.0/odoo/odoo/models.py", line 5897, in __getitem__
    return self._fields[key].__get__(self, type(self))
  File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1198, in __get__
    value = self.convert_to_cache(record._origin[self.name], record)
  File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 1977, in convert_to_cache
    return self._convert(value, record, validate)
  File "/home/nda/dev/odoo/16.0/odoo/odoo/fields.py", line 2000, in _convert
    original_value = record[self.name]
  ...
```

after this commit:
no error

opw-3575865



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

Forward-Port-Of: odoo/odoo#143307
Forward-Port-Of: odoo/odoo#142045

Previously, the datetime field read the value for readonly directly in the attrs when extracting its props when available. This resulted in 2 separate bugs:
- in debug mode, props validation of the datetime picker would fail, as it expects to receive a boolean for the `range` prop.  This was caused by the fact that required was the raw attribute (a string) instead of the boolean and ended up being propagated to the `range` prop
- outside of debug mode, the value for required did not cause a crash but any value for required that was not empty would be interpreted as truthy, causing the field to always be display itself as though it is required. In non-range mode, this is invisible, but in range mode, it would always show the second datetime input and the arrow between the beginning and end date, even with required being 0/False, or a python expression that may evaluate to false

This commit fixes that by instead reading the value for required from the dynamic infos provided to `extractProps`, which will always be a boolean and contain the value of the evaluated expression when appropriate.

Forward-Port-Of: odoo/odoo#143509

Steps to reproduce:
- Install Accounting and Documents
- Go to Documents settings
- Activate "Accounting" option (Workspace: Finance) and add a journal to synchronize (Journal: Customer Invoices - Workspace: Finance)
- Go to Accounting and create an invoice
- Click on Print button and select "Invoices"

=> The following Validation Error can be raised:
"The operation cannot be completed: This attachment is already a document"

(This issue depends on the speed of the platform and doesn't always happen)

Cause:
When printing the invoice, an attachment is created, but no document is created in Documents immediately (as configured in Documents settings). Once the attachment created, it is loaded in the chatter and several calls are made to "register_as_main_attachment" method of the attachment. This method is triggering a write on the related record (i.e. the invoice), which tries to create a document (in Documents) from the attachment. When trying to create the document, it first checks if a document already exists for that attachment.
But in some cases, there can be 2 concurrent calls where the first one has not finished creating the document when the second one checks if a document already exists.
It then tries to create a second document for the attachment and triggers the SQL unique constraint.

Solution:
The creation of the document should not depend on the loading of the attachment in the chatter.
It should be created when the attachment is created. So, when the first attachment of an account move is created, the related document will also be created.

opw-3464593

Forward-Port-Of: odoo/enterprise#51114