Bump spl-token-2022 crate version from 6.0.0 to 7.0.0

[samkim-crypto]

Problem

The spl-token-2022 crate version is still at 6.0.0 while 7.0.0 is out.

Summary of Changes

Updated the spl-token-2022 crate version to 7.0.0. The main logic changes are the following:

• Added the new pausable and scaled ui amount extension to account-decoder.
  • Everything was straightforward, but I do parse the f64 multiplier as a String here since f64 does not implement the Eq trait. Please let me know if there is an alternate preferred method to handle f64 values.
• Added the new pausable and scaled ui amount extension to transaction-status. This should be pretty straightfowrad.
• Updated the transaction-status tests to account for the updated instruction syntax ([program-2022] Make confidential mint/burn function parameters consistent solana-labs/solana-program-library#7570). This should also be pretty straightforward.
• Updated the tests in account-decoder to account for the changes in token-2022: Take decimals into account for UI amount solana-labs/solana-program-library#7540.

I will need to update the RPC as done in #1549, but this will require additional tests, so I decided to defer to an immediate follow-up PR and just focus on the token version bump here. Let me know if you prefer to add the RPC logic changes in this PR.

Fixes #

[LucasSte]

I'm not aware of the usages of floating points in scaled-ui. Comparing floating points directly (even if you convert them to strings) is problematic, since floating points carry rounding errors with them.

Depending on the context, you can define an epsilon for comparison, provided that you know the range these numbers will assume.

Have a look at: https://floating-point-gui.de/errors/comparison/

[samkim-crypto]

@LucasSte I believe that the float values are not actually compared as numbers with UiScaledUiAmountConfig, so it seems that String is okay. @joncinque, do you have thoughts here?

[joncinque]

Looks great! Just a question on using a string in instruction data

[joncinque]

This is using a string elsewhere -- do you want to follow that same convention here?

[samkim-crypto]

Good point. Updated!

[joncinque]

Same here, string?

[joncinque]

@LucasSte I believe that the float values are not actually compared as numbers with UiScaledUiAmountConfig, so it seems that String is okay. @joncinque, do you have thoughts here?

That's correct, these numbers are not used for any logic, just for calculating a UI representation of the token amount. I think String makes the most sense

[LucasSte]

@LucasSte I believe that the float values are not actually compared as numbers with UiScaledUiAmountConfig, so it seems that String is okay. @joncinque, do you have thoughts here?

That's correct, these numbers are not used for any logic, just for calculating a UI representation of the token amount. I think String makes the most sense

Is leaving them out of the comparison an option? I'm afraid a comparison may error out for a silly rounding error.

[joncinque]

Is leaving them out of the comparison an option? I'm afraid a comparison may error out for a silly rounding error.

You mean the checks like this one in the test?

assert_eq!(token_amount.ui_amount_string, "1.051271096376024117");

Yeah sure, we could change the check to starts_with rather than full string equality. What do you think @samkim-crypto ?

[samkim-crypto]

Is leaving them out of the comparison an option? I'm afraid a comparison may error out for a silly rounding error.

You mean the checks like this one in the test?

assert_eq!(token_amount.ui_amount_string, "1.051271096376024117");

Yeah sure, we could change the check to starts_with rather than full string equality. What do you think @samkim-crypto ?

Yeah I think I updated the tests to use starts_with, which seems like a good idea.

I think ideally, we would want the UiScaledUiAmountConfig type to not implement the Eq trait to prevent this type from being compared downstream (this will also allow us to just use f64 values for the multiplier). However, removing Eq from UiScaledUiAmountConfig will require that the UiExtension as well as all the other UI extension types to not implement the Eq type and this starts becoming a large change, so we probably don't want to go that route.

[joncinque]

Looks good to me, but I'll let @LucasSte give the final approval