Make object directly passable in tx's

[gerben-stavenga]

Description

This PR makes (whitelisted) objects directly passable in non-script tx's. The overall strategy is that each allowed struct is associated with a "constructor" in the module that defines the struct, which will construct the type. The argument will be the BCS encoded parameter values of the constructor call, if the constructor takes the same values in the same order as the struct fields this will be identical.

Overall the flow is that a call to eg.

entry fun my_func(x: std::string::String foo) { ... }

let's say my_func("aptos") will effectively be exectuted as if the user has written a script like

let s = std::string::utf8("aptos")
my_func(s)

The same works for objects

entry fun send(x: Object, to: address);

a call send(0xCAFE, 0xC0FFEE)

will effectively run like

let o = aptos_std::object::address_to_object(0xCAFE)
send(o, 0xC0FFEE)

Notice that I included type inference in the call to address_to_object, from the expected return type. The algorithm works recursively so in principle nested structs etc. will work fine.

Test Plan

[davidiw]

TyParam(usize)

what if we get this? what is this even? it would seem like a violation

Also these all have Eq / PartialEq -- why not leverage that?

[wrwg]

We need a fix for the error propagation problem.

[github-actions]

✅ Forge suite land_blocking success on 065ee15cf73298e622a33d4e6cebb844b8b343d2

performance benchmark with full nodes : 5605 TPS, 7002 ms latency, 12100 ms p99 latency,(!) expired 1040 out of 2394480 txns
Test Ok

• Grafana dashboard
• Humio Logs
• Pyroscope Profiling
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite framework_upgrade success on cb4ba0a57c998c60cbab65af31a64875d2588ca5 ==> 065ee15cf73298e622a33d4e6cebb844b8b343d2

Compatibility test results for cb4ba0a57c998c60cbab65af31a64875d2588ca5 ==> 065ee15cf73298e622a33d4e6cebb844b8b343d2 (PR)
Upgrade the nodes to version: 065ee15cf73298e622a33d4e6cebb844b8b343d2
framework_upgrade::framework-upgrade::full-framework-upgrade : 6440 TPS, 5835 ms latency, 9200 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for cb4ba0a57c998c60cbab65af31a64875d2588ca5 ==> 065ee15cf73298e622a33d4e6cebb844b8b343d2 passed
Test Ok

• Grafana dashboard
• Humio Logs
• Pyroscope Profiling
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite compat success on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 065ee15cf73298e622a33d4e6cebb844b8b343d2

Compatibility test results for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 065ee15cf73298e622a33d4e6cebb844b8b343d2 (PR)
1. Check liveness of validators at old version: testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b
compatibility::simple-validator-upgrade::liveness-check : 8160 TPS, 4737 ms latency, 8500 ms p99 latency,no expired txns
2. Upgrading first Validator to new version: 065ee15cf73298e622a33d4e6cebb844b8b343d2
compatibility::simple-validator-upgrade::single-validator-upgrade : 3758 TPS, 10450 ms latency, 14900 ms p99 latency,no expired txns
3. Upgrading rest of first batch to new version: 065ee15cf73298e622a33d4e6cebb844b8b343d2
compatibility::simple-validator-upgrade::half-validator-upgrade : 4438 TPS, 8886 ms latency, 10900 ms p99 latency,no expired txns
4. upgrading second batch to new version: 065ee15cf73298e622a33d4e6cebb844b8b343d2
compatibility::simple-validator-upgrade::rest-validator-upgrade : 6678 TPS, 5549 ms latency, 11400 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 065ee15cf73298e622a33d4e6cebb844b8b343d2 passed
Test Ok

• Grafana dashboard
• Humio Logs
• Pyroscope Profiling
• Test runner output
• Test run is land-blocking