Allow dynamic types in configurables

[xunilrj]

Description

This PR implements "dynamic types" for configurables. This means those types which the encoded bytes buffer does not have a know size at compilation time. For example: Vec, Dictionaries, string slices etc...

The major problem these pose is that the ABI json has the offset to their encoded bytes; and if their buffer size changes, that would invalidate the offset of configurables coming after them inside the json.

To solve this issue, these types will have their buffer read indirectly. This means that, at the predefined offset will be another offset, this last one from the start of the data section that will point to their encoded bytes, which can be shared if needed as it is read-only.

If the buffer is not reused, it is expected that it will live at the end of the binary, where it will not invalidate any of the ABI json offsets.

Example:

Each config at the IR has a new field for some "flags". Currently we only have one flag, which is if the decode is direct (0) or indirect(1). Direct means that the encoded bytes are inside the configurable section. Indirect means that the compiler puts an offset inside the configurable section, but the encoded bytes will be append at the end of the binary.

 // IR: Final
     script {
//                                                              \/ ---------- This is new
         ANOTHER_U8 = config u8, abi_decode_in_place_27, 0x03, 0x00, !1
         ...
         VEC_U8 = config { { u64, u64 }, u64 }, abi_decode_in_place_53, 0x0000000000000000, 0x01, !18

The generated asm now have a new ".offset of", which will be materialized into the offset from the start of .data section (NOT the configurable section).

.data:
     ...
     data_Configurable_STRING_SLICE (9) .offset_of data_Dynamic_STRING_SLICE
     ...
     data_Configurable_VEC_U8 (17) .offset_of data_Dynamic_VEC_U8
     ...
     data_Dynamic_STRING_SLICE (0) .bytes[19] 00 00 00 00 00 00 00 0b 48 65 6c 6c 6f 2c 20 53 77 61 79  ........Hello, Sway
     data_Dynamic_VEC_U8 (1) .bytes[8] 00 00 00 00 00 00 00 00  ........

and the generated bytecode will be:

.data_section:
        ...
         0x00002178 .offset of 0x000021e1, as word 465, as hex be bytes ([00, 00, 00, 00, 00, 00, 01, D1])
        ...
         0x000021d8 .offset of 0x000021f4, as word 484, as hex be bytes ([00, 00, 00, 00, 00, 00, 01, E4])
         ...
         0x000021e1 .bytes as hex ([00, 00, 00, 00, 00, 00, 00, 0B, 48, 65, 6C, 6C, 6F, 2C, 20, 53, 77, 61, 79]), len i19, as ascii "........Hello, Sway"
         0x000021f4 .bytes as hex ([00, 00, 00, 00, 00, 00, 00, 00]), len i8, as ascii "........"

The .data section offset can be read directly from the binary as it lives at the start of the binary.

;; ASM: Final program
;; Program kind: Script
.program:
     move $$tmp $pc
     jmpf $zero i4
     DATA_SECTION_OFFSET[0..32]
     DATA_SECTION_OFFSET[32..64]
     CONFIGURABLES_OFFSET[0..32]
     CONFIGURABLES_OFFSET[32..64]

more precisely at:

;; --- START OF TARGET BYTECODE ---

         0x00000000 MOVE R60 $pc                                    ;; [26, 240, 48, 0]
         0x00000004 JMPF $zero 0x4                                  ;; [116, 0, 0, 4]
         0x00000008                                                 ;; [0, 0, 0, 0, 0, 0, 32, 16]   <- DATA SECTION OFFSET
         0x00000010                                                 ;; [0, 0, 0, 0, 0, 0, 0, 0]
         0x00000018 LW R63 R60 0x1                                  ;; [93, 255, 192, 1]
         0x0000001c ADD R63 R63 R60                                 ;; [16, 255, 255, 0]

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.

[codspeed-hq]

CodSpeed Performance Report

Merging #6760 will not alter performance

_{Comparing xunilrj/dynamic-types-configurables (5ee6a00) with master (1192b3f)}

Summary

✅ 22 untouched benchmarks

[sdankel]

Suggested change

dbg!(&generated_loader_abi_path, &used_loader_abi_path);

[sdankel]

Is the plan to wait for the fuels branches to be merged this PR goes out?