feat: e1,e3 implementation for sha2

[arayikhalatyan]

Implemented e1, e3 for sha2 circuit. I feel like the trace generation of sha2 is more readable now. Probably there is a room for making the inner sha256 trace generation more efficient, I'll try to make some improvements before merging.

Question: are we planning to have the restrictions on block_size (eg alignment and being power of two) in e1 and does it have to be constant? If not I could make the e1 execution to read the entire message in one read.

Resolves INT-3966

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #1657 will not alter performance

_{Comparing feat/sha2-rewrite (9f6f129) with feat/new-execution (00bab47)}

Summary

✅ 4 untouched benchmarks

[codspeed-hq]

CodSpeed Walltime Performance Report

Merging #1657 will not alter performance

_{Comparing feat/sha2-rewrite (9f6f129) with feat/new-execution (00bab47)}

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

Summary

✅ 4 untouched benchmarks

[jonathanpwang]

@arayikhalatyan we shouldn't have any block size restrictions on E1 (but likely need it for E2 in some light form). My imagination is indeed that E1 should just look like input = read_bytes(); return sha256(input)

[arayikhalatyan]

@arayikhalatyan we shouldn't have any block size restrictions on E1 (but likely need it for E2 in some light form). My imagination is indeed that E1 should just look like input = read_bytes(); return sha256(input)

Yeah I agree. Then we have to make some changes to the GuestMemory interface because it expects the block size as a const generic.