"Max Buttons" incorrectly calculate max amounts to Redeem and Unwrap-Weth

[nicholaspai]

There are two problems here:

• The "Max" button in the Redeem feature sets the max amount to redeem equal to the user's balance, even if they have more tokens than # tokens outstanding in their position. This needs to be set to Math.min(tokenBalance, tokensInPosition)
• The amount set to the max is equal to the "intended max" amount casted to a number, and JS casting loses precision. Therefore, the amount set to the max should be equal to the string. This affects both Redeem and UnwrapWETH
  Fixes Redeem should set amounts > num Tokens outstanding to num tokens outstanding #116

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/uma/emp-tools/lx75ono6u
✅ Preview: https://emp-tools-git-npai-max-redeem.uma.vercel.app

[chrismaree]

The types we are dealing with here are pretty janky. it's such a pain to keep having to convert and name the type within the variable. I wish there was a cleaner pattern for this.

[nicholaspai]

The types we are dealing with here are pretty janky. it's such a pain to keep having to convert and name the type within the variable. I wish there was a cleaner pattern for this.

Maybe a better solution is to export both a string version and a number version. This way if we don't want to lose precision we can use string, else number, wdyt? However, I don't like the idea of the "backend" container exporting numbers that have lost precision. I think the container should return as close to raw data as possible.

Alternatively, we could export averything from the containers as BigNumbers so they don't lose precision

[nicholaspai]

@chrismaree I'd like to tackle the type casting in a future PR, but want to make this bug fix for now: #118