### Steps to reproduce:
- Activate developer mode
- Install the 'l10n_ec' module and switch to an Ecuadorian company
- In Settings > Technical > Database Structure > Decimal Accuracy change the number of decimals for "Product Price" to 4 for example
- In Accounting, create a new Customer Invoice
- Select 'Instituto Ecuatoriano' as Customer
- Add a line with a price with 4 decimals
- Select 'Sin utilization del sistema financiero' as Payment Method
- Confirm
- On the blue popup at the top of the page, click 'process now' to get the XML in the chatter
- In the XML the "precioUnitario" field only has 2 precision digits, it has been rounded
- When adding a discount of 100% this field has all precision digits needed

### Cause:
The price_unit is calculated differently if the discount is 100%. The "precioUnitario" field should always have the number of precision digits specified in the settings.

### Solution:
We need to find the unit price without the discount, but without the included. This value is not computed.
As the values computed in the account.move.line are already rounded based on the currency (2 digits) we need to
recompute the values using `compute_all` and multiplying by the `price_digits` to not round in `compute_all`.

The way the rounding is made here is by taking the decimal precision from the settings and making it a power of 10 in `price_digits` (4 decimals results in price_digits = 10000). Then we compute the taxes with `price_unit * price_digits`. As, per definition,  `price_unit` has the number of digits used in the calculation of `price_digits`, we end up with an integer. But after the results of `compute_all` may no longer be an integer. We need an integer to keep the decimal precision. This is why, in the result, there is a call to `round()`.
The call to `float_round()` is to make sure there are not more decimals than 6. This is needed as the number displayed in the XML will always be of 6 decimals, so if the client set a number of decimals greater than 6, it will be rounded in the XML but not on the invoice. To ensure that both values are the same, we round the value here.

Some tests had "precioUnitario" with strange values that did not match the actual price_unit. It was because the precedent way to calculate this field was not perfect, I guess.

opw-4120341

Forward-Port-Of: odoo/enterprise#68555