* update author's name after recent rebranding of Eficent to ForgeFlow.
* change license to lgpl as agreed by the authors.
* update readme to new format.
The computation of the unreserved available amount using the
StockQuant._get_available_quantity was wrong as soon as more than one
quant was found for the same product. It can easily happen when you have
sublocations and a quant in each location.
The reason is that the algorithm was:
1. searching for all the quants for a given product
2. calling StockQuant._get_available_quantity for each quant
3. _get_available_quantity is an @api.model method, which itself will
search for all quants for the product and the given location and
children
Which means that if you have these locations:
Stock
Stock > Bin A
Stock > Bin B
And these quants:
1. Product: Product A
Location: Bin A
Quantity: 60
Reserved: 0
2. Product: Product A
Location: Bin B
Quantity: 10
Reserved: 0
Instead of 70, the result was 140. (One loop for each quant, each loop
recomputing the total quantity in _get_available_quantity, all summed
togethed, for each new quant, an additional sum would be added).
Ultimately, the _get_available_quantity method does the sum of (quantity
- quantity reserved). This commit uses the same logic than the 10.0
branch, it finds the quants contextually using
ProductProduct._get_domain_locations and get the available quantity as
the sum of (quantity - quantity reserved).
We can't really use StockQuant._get_available_quantity because this one
expects a location, while here we don't necessarily know it.
I removed _product_available_not_res_hook which seems to have no
purpose, it does not receive the result of the computation and its own
result is unused.
Read quants without lang into the context to avoid sql join on ir.translations
Iter on product with prefetch_fields=False and lang='' to avoid reading useless column ad join on ir.translations
