Introduce HashedPostStateProvider

[frisitano]

Replacement for #11872

[frisitano]

False negative on failing tests due to #12893

[mattsse]

all of these make sense to me

pending @klkvr and @rkrasiuk

[rkrasiuk]

not a fan of having to initialize hashed post state via provider, but otherwise lgtm

[frisitano]

I accidentally merged some unrelated work but reset and removed those commits back to the previous reviewed state.

[klkvr]

lgtm, although wondering if we could move the HashedPostState construction to StateRootProvider implementation? it looks like from_bundle_state is called pretty much always before invoking it.

That way we'll unify code paths and make sure that hashing is only done by the type that knows the configured state commitment impl

[klkvr]

pending ci and conflicts

[frisitano]

lgtm, although wondering if we could move the HashedPostState construction to StateRootProvider implementation? it looks like from_bundle_state is called pretty much always before invoking it.

That way we'll unify code paths and make sure that hashing is only done by the type that knows the configured state commitment impl

I would be in support of this idea. However, I need to do some analysis to ensure this is practical for all code paths and evaulate what changes would need to be made. I would suggest we proceed with the current direction and add this as an issue to review and refactor once we have the current implementation stabilized. What do you think?