all: use stateless keccak

[pmikolajczyk41]

Context

Keccak hashing algorithm can be used in two ways: (1) as a one-shot hash function (we are just interested in hash of the data that we already have in full) or (2) as a cryptographic sponge (for cases where we don't know all the data to be hashed yet, we need some intermediate hashes, etc.)

From the caller perspective, (1) is a completely stateless process, but (2) requires keeping some state.

The crypto package exposes Keccak256Hash() and Keccak256() functions realizing (1) and NewKeccakState() for (2).

Problem

There are ~20 places where we use stateful approach (2) for (1). In other words, we:

• use NewKeccakState() to create the sponge state
• (optionally) keep it as a field
• use lower-level methods on this object to compute the hash (Write(), Read(), Sum())
  whereas we could (and should) just use Keccak256() utility.

Proposed changes

1. Use stateless keccaking wherever possible. It seems that the only place we actually need stateful one is the spongeDb in some testing.
2. Do some minor refactor to deduplicate logic between Keccak256Hash() and Keccak256()
3. Make KeccakState interface just extend io.Reader instead of inlining io.Reader's method

[gballet]

That reminds me of something I've done before for keeper, I'll have to check that this doesn't clash with those changes. I'm flying today, don't merge before I've had a deeper look.

[rjl493456442]

The changes are not essential, we prefer to not include it.

[pmikolajczyk41]

@rjl493456442 let me at least argument my motivation - when running geth within ZK VM it is highly beneficial to outsource heavy computation (like Keccak) to the dedicated VM precompiles; by removing all unnecessarily stateful hashing and reusing the Keccak256Hash() and Keccak256() utilities, it is way easier to replace all keccak invocations than to worry that some of them will persist in this strange form