Fix division precision loss

[3esmit]

In StakeManager, there are some divisions, but solidity does not support any type of real numbers, so we are using integers where division always rounds down.

For the MP logic, this would break the minting, as it usually would get something like .1, .01, and try to multiply that by the balance to find how much to increase. This will always return zero in current code.

Possible solutions:

1. Multiply by a value (like 100, or 100000, or whatever precision we need) before division, and after divide back this multiplier (fix(StakeManager): use mul by PRECISION and div back later to avoid precision loss in int divisions #67).
2. Use OpenZeppelin Math library (fix(StakeManager): use OpenZeppelin Math to avoid precision loss in int divisions #66)
3. Wait solidity implement fixed point

Read more:

• https://neptunemutual.com/blog/precision-loss-in-solidity-operations/
• https://www.immunebytes.com/blog/precision-loss-vulnerability-in-solidity-a-deep-technical-dive/

[3esmit]

For now, my analysis favors #66 to be approved over #67.

OpenZeppelin mulDiv function uses a smart trick to perform these operations with reduced gas cost, and seems a more safe approch overall.

I'll try to dig more into these solutions to see if I can break one or other in certain scenarios, or if I can improve #67 formulas.

[3esmit]

Duplicate of #24

[0x-r4bbit]

I think going with #66 is a good decision here. It's a battle-tested solution to the problem, this also makes it potentially easier to audit.

[3esmit]

We ended up using OpenZeppelin Math library (#66).

Advantages:

• Audited and battle tested
• Cheaper in gas (at least for the test cases that were created)
• More clear code
• Safer against overflows (if we use a precision multiplier, than for huge values it could overflow)

Disadvantage:

• External library, one more dependency