feat: transparent bindings and bigints

[Cifko]

Description

Handle the #[serde(transparent)] structs, and also fix the bigint. i64 and u64 were exported as bigint, instead of number. The number can hold anything in range(inclusive) from -(2^53-1)...(2^53-1). Anything above or below can be hold but it's not safe to be precise.

Motivation and Context

Some of the structures are #[serde(transparent)] this is not recognized by the ts-rs crate. If the structure is "real struct" (e.g. struct A{b:u64} and not a struct A(u64), then we can call #[ts(flatten)] but you have to call it on every instance. And it will rewrite the variable e.g.

struct A{
  #[ts(flatten)]
  b:B
}

struct B {
  c:u8
}

Will be exported as

export interface A {
  c : number; // instead of b : number
}

So I have decided instead of flatten define the types by hand

How Has This Been Tested?

What process can a PR reviewer use to test or verify this change?

Breaking Changes

• None
• Requires data directory to be deleted
• Other - Please specify

[github-actions]

Test Results (CI)

436 tests  +356   436 ✅ +357   1h 42m 17s ⏱️ + 46m 3s
 57 suites + 41     0 💤 ±  0 
  2 files   +  1     0 ❌  -   1 

Results for commit 535551e. ± Comparison against base commit c29d5b8.

This pull request removes 1 and adds 357 tests. Note that renamed tests count towards both.

tari_dan_common_types ‑ shard::export_bindings_shard

Scenario: Claim and transfer confidential assets via wallet daemon: tests/features/wallet_daemon.feature:89:5
Scenario: Claim base layer burn funds with wallet daemon: tests/features/claim_burn.feature:6:3
Scenario: Claim validator fees: tests/features/claim_fees.feature:6:3
Scenario: Confidential transfer to unexisting account: tests/features/transfer.feature:163:3
Scenario: Counter template registration and invocation: tests/features/counter.feature:7:3
Scenario: Create account and transfer faucets via wallet daemon: tests/features/wallet_daemon.feature:7:5
Scenario: Create and mint account NFT: tests/features/wallet_daemon.feature:133:5
Scenario: Create resource and mint in one transaction: tests/features/nft.feature:73:3
Scenario: Double Claim base layer burn funds with wallet daemon. should fail: tests/features/claim_burn.feature:44:3
Scenario: Indexer GraphQL requests events over network substate indexing: tests/features/indexer.feature:118:3
…

♻️ This comment has been updated with latest results.

[sdbondi]

Loosely tested

Perhaps just change the paths to be correct inside dan_layer so that they go into bindings in the git root. It might be better to package JRPC types for the VN, indexer and wallet in separate NPM packages but we can clean that stuff up at a later point

[sdbondi]

Approving because we can clean the paths up later, since build.sh moves them

btw probably want to add npx infront of shx mv... I get a command not found error in build.sh but if the paths are fixed we can remove the mv commands anyway

[Cifko]

Approving because we can clean the paths up later, since build.sh moves them

btw probably want to add npx infront of shx mv... I get a command not found error in build.sh but if the paths are fixed we can remove the mv commands anyway

done