chore: early check type equality in try_unify

[asterite]

Description

Problem

Resolves #7256

Summary

While debugging this I realized that try_unify was being called with self and other being complex infix expressions that were actually the same type (same type variables, etc.). When that happened canonicalizing and trying to unify both would involve a lot of computations (it ends up trying to unify lots of u32 for a reason that I still didn't sit down to investigate). I tried doing an early equality check in try_unify and, magically, the time to compile the relevant program went from 10 minutes to 3 seconds.

(I also didn't investigate yet why the same two types end up being unified)

Additional Context

I think checking for equality here is fine because it means there's nothing to unify, but let me know if this is not okay.

The second commit is just a micro-optimization: when doing if let (_, _) = (a, b), a and b are evaluated and then pattern-matched. Because evaluate_to_field_element might be an expensive call this just ends up doing one of those calls if it ends up returning Err.

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: ccf9c99	Previous: fc75298	Ratio
AztecProtocol_aztec-packages_noir-projects_noir-protocol-circuits_crates_blob	62 s	50 s	1.24

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[TomAFrench]

Awesome, can we create a regression test out of that branch? I'm not sure how much we can just pull out the changes made in that branch vs the full contract.

[jfecher]

Had to double check the raw equality check on types worked as expected but it does and monomorphization relies on this as well to some degree.

[asterite]

I tried. Or, well, at least I tried with a program that had get_arr_of_size__log_bytes_padding__from_plaintext and all the necessary functions, called it in a similar way done there... but it ends up being fast. I still see a lot more work is done before this PR in that case, but I couldn't find a program that would take a lot of time. I'll try it in a follow-up PR.

As a side note, I was curious if this generally improved compile times. In Aztec-Packages master running nargo compile --force --skip-brillig-constraints-check --silence-warnings takes 46 seconds before this PR, and 19 seconds with this PR 🎉