Large Package Publishing module with e2e-move tests

[0xjunha]

Description

• Updated large_packages.move module in move-examples for better data handling and supporting object code deployment.

  • Utilizing SmartTable in the StagingArea to store package code data
  • Entry function stage_code_chunk supports 1) deploying to a standard account 2) deploying to an object 3) upgrading object code

• Added e2e-move tests for publishing large packages using large_packages.move with following test cases:

  • publishing large package
  • upgrading large package
  • upgrading large package (fail; incompatible modules)
  • upgrading large package (fail; immutable package)
  • upgrading large package (fail; overlapping modules)
  • publishing large package to object
  • upgrading large package deployed under an object

Next Steps

Deploy large_packages.move:

• Deploy as an immutable contract or include it in the aptos-framework after security audits.

CLI Command Updates:

• Add a new option flag (e.g., --chunked) to aptos move publish and aptos move create-object-and-publish-package to support utilizing large_packages.move for publishing large packages from the CLI. (cc. @JohnChangUK )

SDK Updates:

• Ensure SDKs support serializing the Option Move type, as the entry function large_packages::stage_code_chunk receives the Option type.
• Since the object address is derived from the user account and sequence number, we need a way to calculate the publisher's sequence number when the package is finally deployed, after multiple transactions of staging code. This will allow us to specify the object address as a named address. For example, if a large package requires 4 staging transactions and 1 final publishing transaction, (current sequence number) + 1 + 4 will be the sequence number when the package is finally deployed.

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

How Has This Been Tested?

cargo nextest run large_package_publishing

Checklist

• I have read and followed the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I identified and added all stakeholders and component owners affected by this change as reviewers
• I tested both happy and unhappy path of the functionality
• I have made corresponding changes to the documentation

[trunk-io]

⏱️ 4h 45m total CI duration on this PR

Job	Cumulative Duration	Recent Runs
rust-move-unit-coverage	1h 20m	🟩 🟩 🟩 🟩 🟩
rust-move-tests	1h 9m	🟥 🟥 🟩 🟩 🟩
rust-targeted-unit-tests	59m	🟩 🟩 🟩 🟩 🟩
rust-lints	35m	🟥 🟩 🟩 🟥 🟩
run-tests-main-branch	21m	🟩 🟩 🟩 🟩 🟩
general-lints	9m	🟩 🟩 🟩 🟩 🟩
check-dynamic-deps	8m	🟩 🟩 🟩 🟩 🟩
semgrep/ci	2m	🟩 🟩 🟩 🟩 🟩
file_change_determinator	58s	🟩 🟩 🟩 🟩 🟩
file_change_determinator	56s	🟩 🟩 🟩 🟩 🟩
permission-check	18s	🟩 🟩 🟩 🟩 🟩
permission-check	15s	🟩 🟩 🟩 🟩 🟩
permission-check	15s	🟩 🟩 🟩 🟩 🟩
permission-check	13s	🟩 🟩 🟩 🟩 🟩

🚨 2 jobs on the last run were significantly faster/slower than expected

Job	Duration	vs 7d avg	Delta
rust-move-unit-coverage	13m	16m
rust-targeted-unit-tests	10m	18m

_{settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 33.1%. Comparing base (415d7e1) to head (a3473b4).
Report is 1 commits behind head on main.

❗ Current head a3473b4 differs from pull request most recent head 0401e12

Please upload reports for the commit 0401e12 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff            @@
##             main   #13344     +/-   ##
=========================================
- Coverage    33.1%    33.1%   -0.1%     
=========================================
  Files        1753     1753             
  Lines      337769   337769             
=========================================
- Hits       112041   111808    -233     
- Misses     225728   225961    +233     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JohnChangUK]

Would it be better to have the object publish/upgrade command in a separate API? i.e. stage_object_code_chunk? Then we don't need to pass in all the bools in a single function.