feat: add function for generating bytecode identifier

[sdankel]

Description

Depends on #6522
Related FuelLabs/forc.pub#16

Adds a function, get_bytecode_id that generates a sha256 hash of the bytecode with the configurables section of the bytecode removed. This will be used for indexing and lookups of the corresponding ABIs for contracts, predicates, and scripts in the package registry (forc.pub).

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[sdankel]

This is currently blocked because the related compiler change was reverted.

[JoshuaBatty]

Nice! Appreciate all the comments done here as well.

[zees-dev]

Great work!

Do you think it would be worthwhile having the source .sw files for the contracts aswell as the binary files?
I can potentially imagine a scenario where we could have compiler changes, and hence the output binaries may not be regeneratable.
Having the source alongside would potentially help resolve such future test failures i'd imagine.

[sdankel]

Great work!

Do you think it would be worthwhile having the source .sw files for the contracts aswell as the binary files? I can potentially imagine a scenario where we could have compiler changes, and hence the output binaries may not be regeneratable. Having the source alongside would potentially help resolve such future test failures i'd imagine.

Thanks for bringing this up. I thought about having the tests generate the binary files from the source, but thought that it would be annoying to have to update the bytecode IDs in the tests whenever the compiler changes.

I figured that if the tests aren't regenerating the binary from source, there was no need to include the source, since the source projects are already checked in under examples/

When we need to regenerate the binary files in the future, it would just be a matter of building those two examples with forc build and forc build --release and updating the bytecode IDs in the tests. Let me know what you think.

[zees-dev]

I figured that if the tests aren't regenerating the binary from source, there was no need to include the source, since the source projects are already checked in under examples/

Didn't know the the source is already in examples; in that case no need for another source.
Agree that compilation would still be issue regardless - if compiler changes.

Just thinking from the point of someone else having to fix the tests if they break.
A comment in the test(s) themselves could help (point to examples).
Nevertheless will leave this upto you.

[sdankel]

Just thinking from the point of someone else having to fix the tests if they break. A comment in the test(s) themselves could help (point to examples). Nevertheless will leave this upto you.

Good idea. I'll add a comment in a separate PR since this one is pretty much ready to go.