Commit 1.

Before this commit, `Record.onChange` binds its two functions to what `this` is at the call site. A record is only reachable as its proxy once the constructor is over, so a registration has to wait for `static new`, where `super.new` has returned it, and both models that register one override `static new` for nothing else.

This commit resolves the proxy when the functions run rather than when they are registered, so `setup` can register an onChange, and moves both models to it.

Commit 2.

Before this commit, a value computed from a record can only be a field with a `compute`, and the model guesses whether that value needs storing: `fieldsComputable` picks the lazy plain-valued fields with eight conditions and a regular expression run on the compute's source.

This commit adds `fields.computed()`, so the declaration answers instead of the model: the value is computed on the first read and kept in an owl computed of its own, which the model neither stores nor serializes. The 36 fields the detection was picking are declared instead, so `fieldsComputable` lists what the declarations name and the guessing goes. A `compute` left on a field is scheduled and stored. A computed has no `onUpdate`, so the two fields that had one register an `onChange` from `setup`.

This also converts four getters that rebuild a collection on every read, so each one runs on a change instead of on every read.

This also fixes what the conversion turned up:

- `extra_body_attachment_ids` is declared as an `Attr` whose target model lands as its default value, where the compute returns records: the field becomes a `Many`.
- three writes to `is_pinned` in `discuss.channel` never reach the member, as its compute owns the value: opening a channel, opening its chat window and undoing an unpin now set `unpin_dt`, what the compute reads and what the server writes to pin. `updateAttr` warns on such a write instead of dropping it in silence.
- `crm.lead` has no `models` declaration and no `@crm` path alias, so the `@this` of its compute names the raw class and the computed value stays untyped. The enterprise counterpart declares `helpdesk.ticket` the same way.

Commit 3.

Before this commit, a value that goes stale on its own is kept by `Record.computedUntilStale`, a per-record store of its own next to the one `fields.computed` uses. The problem is that the same value needs a key repeating its name, a getter to read it through, and a second place to look for a record's computeds.

This commit takes the delay as a third argument of `fields.computed`, so the two clock values of the store are declared like any other computed, and `staleComputeds` goes.

Confirming a purchase order of 1000 lines
- with only stock & purchase : time is 6.3secs
- by adding mrp : time grows to 8.1secs

Part of the difference comes from the time it takes to explode the (potential) kits.

The refactor of _bom_find consists of:
- signature change : company_id -> company_ids to allow searching within multiple companies in one go
- return value change : the returned dict's key is now a tuple ( product, company_id or False)

Calling _bom_find with no company given
: retrieve result with ( product, False)
Calling _bom_find with one or more company_id's
: retrieve result with ( product, company)
-> for _bom_find on record sets having the fields product_id & company_id

With this, use case time falls to 6.9secs

This will obviously have performance impact on many use cases.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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