upstream GDA based decimal type

[aaronc]

Based on the discussions in #7773, the decision regarding decimals in the SDK is to use a GDA-based decimal implementation to replace the current sdk.Dec.

This would likely be based on one of these two libraries and we should plan on providing upstream changes when needed:

• https://github.com/cockroachdb/apd
• https://github.com/ericlagergren/decimal

This new decimal type should likely go into a new standalone math go module along with a copy of the current sdk.Int implementation so these are broken out of the monolithic SDK.

The apd-based Dec wrapper type in regen-ledger can possibly be the basis for this new math.Dec type: https://github.com/regen-network/regen-ledger/tree/master/types/math

[alexanderbez]

The apd-based Dec wrapper type in regen-ledger can possibly be the basis for this new math.Dec type: https://github.com/regen-network/regen-ledger/tree/master/types/math

Assuming we have a math go sub-module, can we just copy/upstream the Regen type(s)?

[aaronc]

The apd-based Dec wrapper type in regen-ledger can possibly be the basis for this new math.Dec type: https://github.com/regen-network/regen-ledger/tree/master/types/math

Assuming we have a math go sub-module, can we just copy/upstream the Regen type(s)?

If we agree the regen API and behavior is what we want. It is based off of 128-bit decimal arithmetic, but can have configurable rounding

[robert-zaremba]

Is there anything blocking adding the Regen version? I can port the it if nobody is looking at it.

[faddat]

I don't have a ton of context here, but I wanted to bring this Twitter feedback here:

https://twitter.com/smsunarto/status/1676769181520523265

Scott also mentions that regen's wrapper cures the issue he was describing.

Go Regen!

[tac0turtle]

done