## Analysis
Since the POS changed to introduce frontend relational models, we load all missing records whose model belongs in the `"missingModelsAllowedToLoad"`.

If a user implements `loyalty.rewards`, the field `all_discount_product_ids` can contain a lot of data (more than often, all products), which may slow down or block the opening of POS.
The issue is the same for `loyalty.rule` and the field `valid_product_ids `which usually contain all products.
The resulting `loadData` and `read` on` product.product `become exponentially long to compute.

## Solution
This commit makes use of the `CONFIG` parameter to introduce a way to restrict the loading of these fields (and any other field which may cause performance issues) to the POS.

## Benchmarks
`read` on `product.product` during the opening of POS:
|  all_discount_product_ids   | Before  | After  |
|-------------|---------|--------|
| 8635 records| 2.4 min  | ~2 s |
| 14244 records| 2.9 min  | ~2 s |

## Note
This is probably not a perfect solution but might be a fix to let clients open their POS until we find a better solution.

## References
Several clients are running into very long PoS loading time:
opw-3906475
opw-3917017

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