P-261 Refactor Achainable type definitions

[grumpygreenguy]

Context

• Reduce some repetition in Achainable request type defs.
• Use the BoundedWeb3Network type for the chain param everywhere

How (Optional)

Initial proposal was to extract the common fields to a struct, but they don't really seem to make semantic sense as a single type. Extracted them as a macro instead, which also allowed a bunch of repeated derive annotations to be deduplicated.

TODO

• Validate approach
• Fix resulting type errors from incompatible chain param type
• Fix TS tests

[linear]

P-261 Merge Achainable request structure

[grumpygreenguy]

@zhouhuitian @Kailai-Wang in the (existing) AmountToken case we're just using the first chain in the vector; is that a reasonable solution for the rest of the assertions, or should we make a more significant fix?

[Kailai-Wang]

Thanks! I invite @zhouhuitian to review it too

[Kailai-Wang]

@zhouhuitian will be back in one week (probably) - so we could merge it before it dangles for too long and make retroactive changes later if required.

However, we need to be very cautious about releasing and deploying it. We'll need confirmation from @zhouhuitian and ideally client colleagues (@jonalvarezz and @YoshiyukiSakura) to make sure we don't break anything for the current VC request construction.

[jonalvarezz]

Nice!

From the client side, I don't expect many changes as Assertion types are only used for requesting and since the enum isn't changing, it seems to be scoped down to the Web3Network -> Vec<Web3Network> change.

I created this ticket to follow up and adjust client-sdk correspondingly: https://linear.app/litentry/issue/P-514/client-sdk-update-types-accordingly-after-achainable-types-rework