Unify Decimal Precisions used for Transfer Amounts

[enjeyw]

Is your feature request related to a problem? Please describe.
When we started building the system, we used integers representing cents everywhere where we manipulated transfer amounts - ie $12.50 was represented as 1250. On the front end, the decimal place was then added as the last step.

As more integration with ERC20 tokens was introduced, we started needing to manipulate amounts large amounts of precision (typically 18 digits). Largely we've worked around this by storing the full precision amount as a numeric type in the db, and converting to a float (still representing cents) for manipulation, but this is inconsistent and introduces all kinds of small rounding errors.

Describe the solution you'd like

We should introduce a unified process for working with amounts on the backend, probably using python's decimal type everywhere. Requirements:

• Doesn't introduce rounding errors for standard mathematical operations
• Scales on the db without killing query speed
• Work natively with tokens with varying amounts of precision (normally 18, but often much more or less)
• Plays nicely with api clients who don't have a lot of bandwith, even when sending large lists of txns - this one may mean that users cant work with full 18 digit precision, but that's (propbably) ok

[tristanhcole]

Unify Decimals

[michielderoos]

Floating point error resolved in #737