Original PR description

Issue -->

`product.product's` display_name appends the variant's combination name, which `_get_combination_name` builds by dropping the values that come from single value lines. The check behind that, `_is_from_single_value_line`, only needs to know whether the line holds exactly one active value, but it filtered the line's entire set of values through `_only_active()` to find out.

That check runs once per attribute value of every variant being named, so its cost follows the number of values on the template rather than the number of lines.

Solution -->

Stop at the second active value instead: finding two is enough to know the line is not single valued. The archived path (only_active=False) only measures the line's length and is unchanged, as is the returned name in both cases.

Benchmark ->

Reading display_name for the 23989 variants on the related database loads in the Point of Sale from approximately 200s to 70s.

opw-6530735

Original PR description

**Problem:**
Searching on free_qty can be slow when there are many stock.move and stock.quant. The search method uses _compute_quantities_dict() to compute the free_qty based on stock.move and stock.quant, which is expensive.

**Solution:**
A similar field, qty_available, has a faster search method based on stock.quant only. This method can be adapted to support fast searching on free_qty by also aggregating the reserved_qty and subtracting it from the qty_available.

**Perf Table:**
Record: product.template, with ~20k stock.picking and most products w/o moves.

|Record count|Time before|Queries before|Time after|Queries after| 
|------------|-----------|--------------|----------|-------------|
|10k         |2.14s      |214           |370ms     |45           |
|50k         |6.06s      |644           |829ms     |50           |
|100k        |11.42s     |1196          |1.05s     |46           |

opw-6266096

Forward-Port-Of: odoo/odoo#270434