Revert tolerance for share group balance validation

[louispt1]

Context

Change tolerance for share group balance validation from 1.0E-12 to 10E-2 to revert to the previous behaviour of allowing a 1% tolerance for share group balance validation.

See quintel/pyetm#197 for more context. The stricter balancing was causing problems for API users.

Checklist

• I have tested these changes
• I have updated documentation as needed
• I have tagged the relevant people for review

[louispt1]

@noracato
Unfortunately force_balance doesn't work --> when provided shares sum to just over 100, the balancing algorithm tries to solve this by adjusting the unset inputs (which are already at 0). force_balance only allows overwriting previously set share groups, rather than the current set of changes.

I would suggest we catch a diff of ~ 1e-6 and rescale in that case. We can handle that either in pyetm or the engine - but probably in the engine is more robust?

One question is if we rescale with each value by 100/share sum (leading to lots of odd numbers with long decimal trails) or if we use an inverse of the "Hare-Niemeyer method" used in the amalgamator to redistribute the 'remainder' of a share group's total based on the 'entitlement' weights of member shares.

[noracato]

THB if we really want to solve it clean, add a case to quintel/osmosis for when all values are marked static with a simple 100/share sum rescale. Then autobalance will just take care of it. And if people don't want their shares autobalanced, they can already turn it off