FileCreate/FileUpdate automatic chunking

[jbair06]

🆕🐥 First Timers Only

This issue is reserved for people who have never contributed to Hedera or any open source project in general.
We know that creating a pull request (PR) is a major barrier for new contributors.
The goal of this issue and all other issues labeled by 'good first issue' is to help you make your first contribution to Hedera.

👾 Description of the issue

When creating or updating a file using the FileCreateTransaction or FileUpdateTransaction, if the contents are too large for a single transaction, a FileAppendTransaction is required to be created in addition to the FileCreate/FileUpdate.

FileAppendTransaction, on the other hand, can handle a large content because it does chunking of that content internally. It would be good to have FileCreate and FileUpdate to have this same functionality. This would allow for a single transaction to create or update a file with a large content.

Proposed Solution:

Refactor FileCreateTransaction and FileUpdateTransaction to share the new protocol FileTransaction which should include an append(_ transaction: Transaction) method to store additional transactions when the content exceeds 1024 kB. Refer to FileAppendTransaction for an example of how to chunk the content.

Implementation:

1. Create a new protocol FileTransaction
2. Create a base class FileTransactionBase that implements FileTransaction
3. Update FileCreateTransaction and FileUpdateTransaction to implement FileTransaction
4. Create tests to verify the new functionality (unit tests and integration tests)

📋 Step by step guide to do a contribution

If you have never contributed to an open source project at GitHub, the following step-by-step guide will introduce you to the workflow. More information and concrete samples for shell commands for each step can be found in our CONTRIBUTING.md file.
A more detailed general documentation of the GitHub PR workflow can be found here.

• Claim this issue: Comment below that you are interested in working on the issue
• Wait for assignment: A community member with the given rights will add you as an assignee of the issue
• Fork the repository: You can do that in GitHub (by simply clicking the 'fork' button).
• Check out the forked repository
• Create a feature branch for the issue. We do not have a hard naming definition for branches but it is best practice to prefix the branch name with the issue id.
• Solve the issue in your branch.
• Commit your changes: Here, it is needed to add sign-off information to the commit to accept the "Developer Certificate of Origin" (https://developercertificate.org). More details can be found in our CONTRIBUTING.md
• Start a Pull Request (PR): We have a pattern for naming pull requests that a GitHub Action checks. We use that pattern to support the creation of automatic release notes.
• Check GitHub Actions: Several GitHub Actions will be triggered automatically for each PR. If a GitHub Action fails and you do not understand the cause of that error do not hesitate to add a comment to the PR and ask the Hedera developer community for support.
• Wait for reviews: Members of the Hedera developer community will review your PR. If a reviewer finds any missing pieces or a problem, he or she will start a discussion with you and describe the next steps for solving the problem.
• You did it 🎉: We will merge the fix in the develop branch. Thanks for being part of the Hedera community as an open-source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a chance to receive cool goodies like a T-Shirt. 🎽

🤔 Additional Information

If you have any questions, just ask us directly in this issue by adding a comment. You can join our community chat at Discord. A general manual about open-source contributions can be found here.

[tboltondev]

I'm interested in working on this issue, can someone assign it to me?

[tboltondev]

I'm not sure if I'm missing something but following the instructions to set the project up for development when running the commands from the Generate Mirror section, I'm guessing this comment # cwd: $REPO/sdk/swift means I should change into /sdk/swift but I don't have these directories?

[RickyLB]

@tboltondev Disregard that path. If you run git submodule init, the protobuf submodule will it will be populated. Afterwards, using the protoc GenerateMirror command should generate Swift code.