fix!: Change serialization of struct field order to match the user defined order

[jfecher]

Related issue(s)

Resolves #1110

Description

Summary of changes

When serializing contracts, struct fields were previously serialized alphabetically. This change will serialize them in the order defined by users when declaring the struct instead.

Dependency additions / changes

Test additions / changes

Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt with default settings.
• I have linked this PR to the issue(s) that it resolves.
• I have reviewed the changes on GitHub, line by line.
• I have ensured all changes are covered in the description.

Documentation needs

• This PR requires documentation updates when merged.

Additional context

[guipublic]

Using a fixed serialisation pattern, like the alphabetical order for instance is more reliable and avoids user errors based on field struct ordering. I wonder if we could not find a way to keep a fix ordering?

[jfecher]

Reassigning this to @kevaundray for the remaining errors.
Locally the poseidenperm test is failing, and a different test is failing on the CI.

[TomAFrench]

Some comments from when I was looking through this earlier.

[kevaundray]

For more context:

I added another example with a simple struct which also fails:

use dep::std;

 struct myStruct {
     foo: u32,
     bar: Field,
 }

 fn main(y : pub myStruct) {
     constrain y.foo == 5;
     constrain y.bar == 7;
 }

But if we re-order the struct to be in alphabetical order, it will pass like so:

 struct myStruct {
    bar: Field,
    foo: u32,
}

[jfecher]

There must be a case I missed regarding the ordering. Perhaps during verification

[kevaundray]

There must be a case I missed regarding the ordering. Perhaps during verification

Yeah looking to see if we forgot to change something from a BTreeMap

[TomAFrench]

You haven't adjusted the ABI encoding code to use this new ordering logic. This means when constructing the initial witness you're reversing the two fields.

noir/crates/noirc_abi/src/lib.rs

Lines 289 to 293 in 6fe27e7

	InputValue::Struct(object) => {
	for value in object.into_values() {
	encoded_value.extend(Self::encode_value(value)?);
	}
	}

[TomAFrench]

Should be good to go now.

[TomAFrench]

Just noticed the panic in CI. Looking into it now

[TomAFrench]

This may take some larger refactoring. It's pretty gross.

[kevaundray]

Could you open up an issue re the hack and the larger refactoring needed

[kevaundray]

One comment re tracking the issues/hacks we have added, so we can fix them in the future