feat(types): add custom types for authorities, plugins and asset

[shotgunofdeath]

Description

1. Custom test types for plugins, asset with plugins, authorities are added
2. New test fetchAsssetWithPlugins() is added
3. New addAuthorityWithTestFetch test is added, to demonstrate new asset fetching handling
4. Authority and plugin helpers are moved to this PR.

[blockiosaurus]

This looks great! I'll leave it to @nhanphan to approve since he works more with the devex side of things.

[nhanphan]

Overall Asset structure looks good, only had minor questions/comments

[nhanphan]

I think we should hide this (i.e. skip it, it should not appear on the asset)

[shotgunofdeath]

Done. 3e741c6

Though, I'm not sure what a more convenient way to handle this with mapping functions would be. I have 2 options:

1. For now, I restrict that on the type level. It means that when using map helpers and working with Kinobi-generated Plugin type we will have to check if a plugin is not of a Reserved kind. (e.g. registryRecordsToPluginsList())
2. We might allow accept the Plugin type as is, but then we will have to return null/undefined, when mapping a plugin. And if it's used in loops, we'll have to filter those null/undefined.

Do you have any thoughts on that?

[nhanphan]

we should add offset as well. IIRC it's in the registry per plugin just in case anyone wants to do binary stuff with the underlying uint8 array

[shotgunofdeath]

Done. 3e741c6

[nhanphan]

when would you imagine we use formPluginRegistry and formPluginWithAuthorities since I think the original thought was to use them for the t.like(asset,... things. Were you thinking that we'd also use them to submit instructions via say create or something?

[shotgunofdeath]

I've written the explanations on this topic in Slack. Let me copy it here:

So, if we go with custom types we can probably drop a couple of plugin helpers, namely formPluginRegistry() and formPluginWithAuthorities() since we won't have the registry field and the AssetWithPlugins type will have a different structure. formPluginHeader() might still be useful, because we decided to leave the pluginHeader field.

I don't see use cases for that couple of helpers yet. Removed those for now. 3e741c6

[nhanphan]

@blockiosaurus thoughts on just straight overriding fetchAsset with this? i.e. the client lib exposes this as fetchAsset and don't expose the generated fetchAsset?

is there any reason not to deserialize the whole thing always since it's in a single account?

[blockiosaurus]

I'm conflicted. I do like having an explicit fetch with plugins but maybe that'll just be confusing.

[shotgunofdeath]

Is it possible, that someone would like to fetch an asset without plugins?

[nhanphan]

besides feedback from @blockiosaurus on that one comment, this looks good to me. we should replicate the same thing (in another PR/change) to collection as well.

[shotgunofdeath]

@nhanphan @blockiosaurus

143e99b

The old fetchAssetWithPlugins() is replaced with the new one and used in tests.
The new fetchCollectionWithPlugins() is added and also used in tests
Types/naming/mapping funcs are updated according to recent changes.

P.S. Couldn't use fetchAsset() for new fetch funcs, since we need maybeAccount there and it's not returned by fetchAsset()