feat: track assets with utxos

[jkawan]

1. Create Assets table and related get and set functions
2. Added Assets to Utxo table

For the fields in Assets table, took reference from this : https://github.com/Andamio-Platform/andamio-indexer/blob/master/database/plugin/metadata/sqlite/models/asset.go

Closes #339

[wolf31o2]

This is in the right direction. Since Asset is always connected to Utxo, they should be saved along with Utxo and returned with them.

[wolf31o2]

Sorry for being unclear previously. Getting Assets by UTxO should use the reference, the combination of txId []byte and idx uint32 which we can look up the Utxo using the compound index.

[wolf31o2]

Remove write functionality here. The only way to create/update/delete an asset is via a transaction and a UTxO. You should move handling of the assets to the Utxo functions.

[wolf31o2]

This should be assets (it's multi-asset, so multiple). Add them to tmpUtxo.Assets before saving tmpUtxo if it's not nil.

[wolf31o2]

We need to add assets to the Utxo struct above so this doesn't need to change.

[jkawan]

@wolf31o2 what should be the type for assets in Utxo struct here ?

[wolf31o2]

*lcommon.MultiAsset[T]

[agaffney]

The type that we're getting from d.metadata.GetUtxo() is a models.Utxo with an embedded []models.Asset. We can create a duplicate Asset type in this package and modify the duplicate Utxo type accordingly in the short term, but we're eventually going to need to do some conversion to get it back in a lcommon.MultiAsset. It probably makes sense to just do that here, since this PR already has a conversion function for the other direction.

[wolf31o2]

While trying to test this, I ran into an interesting issue.

{"time":"2025-10-02T20:36:17.258199-04:00","level":"ERROR","msg":"failed to process block: add produced UTxO: sql: converting argument $36 type: uint64 values with high bit set are not supported"}

This only occurs with Asset tracking. Checking the Dingo tip, we're here:

Ledger Tip: Slot: 31283557, Hash: d6dba37f653ebfa2f6bd8261673e270f7c03ada3cef86a7f48f34144aee373d5

The block after d6b is bf6bdd159d595cac19ebd2b51ff4cb81b6022192372288718e528de26581ac2f which includes Tx 901d297b9c56b2e8efd273c3778c90636d62a304e4f291029dc271e1ce5f00ce which is doing some mad stuff with minting and outputs.