Stacktrie allocs 2

[holiman]

The PR #30743 improves derivesha:

goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
                          │ derivesha.1 │             derivesha.2              │
                          │   sec/op    │    sec/op     vs base                │
DeriveSha200/stack_trie-8   477.8µ ± 2%   430.0µ ± 12%  -10.00% (p=0.000 n=10)

                          │ derivesha.1  │             derivesha.2              │
                          │     B/op     │     B/op      vs base                │
DeriveSha200/stack_trie-8   45.17Ki ± 0%   25.65Ki ± 0%  -43.21% (p=0.000 n=10)

                          │ derivesha.1 │            derivesha.2             │
                          │  allocs/op  │ allocs/op   vs base                │
DeriveSha200/stack_trie-8   1259.0 ± 0%   232.0 ± 0%  -81.57% (p=0.000 n=10)

This PR takes it one step further. It allows the derivesha method to hand a bytepool to the hasher. The stacktrie can thus use this to feed value-buffers back to the caller, and thus we can avoid a lot of common.CopyBytes.

It's not very elegant, but it does reduce the allocs even further:

goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
                          │ derivesha.2  │             derivesha.3             │
                          │    sec/op    │    sec/op     vs base               │
DeriveSha200/stack_trie-8   430.0µ ± 12%   467.1µ ± 19%  +8.64% (p=0.023 n=10)

                          │  derivesha.2  │             derivesha.3              │
                          │     B/op      │     B/op      vs base                │
DeriveSha200/stack_trie-8   25.654Ki ± 0%   5.494Ki ± 0%  -78.59% (p=0.000 n=10)

                          │ derivesha.2 │            derivesha.3             │
                          │  allocs/op  │ allocs/op   vs base                │
DeriveSha200/stack_trie-8   232.00 ± 0%   37.00 ± 0%  -84.05% (p=0.000 n=10)

Definitely not merge:able as is, putting it up for discussion

[holiman]

It allows the derivesha method to hand a bytepool to the hasher. The stacktrie can thus use this to feed value-buffers back to the caller,

A cleaner way to approach it would instead be to

• on Update, always copy the value, so it's owned by the stacktrie
• Whenever a value is released, put it into an internal pool