feat: implement getTokenInfo for Hardhat

[acuarica]

Description:

This PR implements getTokenInfo for Hardhat. It extends the getHtsStorageAt to interpret Solidity structs and arrays together with support for more types.

Related issue(s):

Fixes #141.

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[victor-yanev]

I don't think this would work, because the actual TokenInfo struct has very different fields for the custom fees from those which are in the mirror node response

[acuarica]

Yes, true that. Going to fix it.

[acuarica]

I think it would be better to tackle this in another PR. The reason being, our tests don't cover custom fees. This implies creating custom tokens with the desired fees, which in itself seems out of scope. What do you think?

[victor-yanev]

Sure, sounds good.

Btw, what I did to test things out for the custom fees (while doing the foundry solution) was to mock some data inside the json files for USDC and MFCT tokens and compare the results from getTokenInfo with the data

[victor-yanev]

Isn't this supposed to be part of the expiry struct? Why are we mapping it directly to a second field? Also, what about the auto-renewal account?

[acuarica]

It is, but these structs are flattened, so it uses the last part of field path, i.e., .second.

For the same reasons, the auto-renewal fields didn't need any extra care.

[victor-yanev]

Alright, makes sense. Let's add a small comment to clarify this.

[victor-yanev]

This method seems really hacky and tries to hit multiple rabbits with a single bullet. The flatten method also seems to have multiple purposes and is really hard to read and follow through.

Wouldn't it be better if we just constructed a new object that would represent the TokenInfo struct and mapped the mirror node response to it?

For example, one way to do it can be by defining a new class that will represent the TokenInfo struct:

• in its constructor (or through a static method - e.g., fromMirrorNodeToken) it can be created from the mirror node object - something similar to what is done in _initTokenInfo in the foundry solution where the TokenInfo struct is being populated from the mirror node JSON response.

Then in order to fill the slots we would have to:

1. Construct an instance of the TokenInfo object, by populating it from the token response from mirror node
2. Iterate through the fields of the TokenInfo object and use the storage layout to figure out the slots where each field should be residing

This seems way easier to understand and also would be very similar to what is done in the HtsSystemContractJson._initTokenInfo method

[acuarica]

Mmm, so 1. and 2. is essentially what slotMapOf is doing. The first bit corresponds loosely to 1., but just amending the token so it's compatible with the Solidity definition. The second part is doing 2., but driven by the storage layout instead.

getHtsStorageAt is driven by slot number (not fields), so to me it's more clear to follow the storage layout first.

[victor-yanev]

Okay, can we create a new object, instead of amending the token object? Also, in the new object we can directly write all fields explicitly in camelCase (as they are in the solidity struct), instead of snake case (this would skip the conversion logic).

In this way it would be more explicit and clearer what fields exist in the mapped object and what we are doing, amending the token object is kind of ambiguous because we are only adding the missing fields and requires us to believe that the actual response will contain the rest of the fields, instead of catching any potential problems (missing fields, etc) on time.