Reclaim memory manually in some tests that fuzz the beacon state

[rkapka]

What type of PR is this?

Tests

What does this PR do? Why is it needed?

#15292 is currently blocked because unit tests that involve fuzzing the state use a ridiculous amount of memory. An example is

prysm/beacon-chain/core/altair/attestation_test.go

Lines 460 to 482 in f5a9394

	func TestFuzzProcessAttestationsNoVerify_10000(t *testing.T) {
	fuzzer := fuzz.NewWithSeed(0)
	st := &ethpb.BeaconStateAltair{}
	b := &ethpb.SignedBeaconBlockAltair{Block: &ethpb.BeaconBlockAltair{}}
	for i := 0; i < 10000; i++ {
	fuzzer.Fuzz(st)
	fuzzer.Fuzz(b)
	if b.Block == nil {
	b.Block = &ethpb.BeaconBlockAltair{}
	}
	s, err := state_native.InitializeFromProtoUnsafeAltair(st)
	require.NoError(t, err)
	if b.Block == nil || b.Block.Body == nil {
	continue
	}
	wsb, err := blocks.NewSignedBeaconBlock(b)
	require.NoError(t, err)
	r, err := altair.ProcessAttestationsNoVerifySignature(context.Background(), s, wsb.Block())
	if err != nil && r != nil {
	t.Fatalf("return value should be nil on err. found: %v on error: %v for state: %v and block: %v", r, err, s, b)
	}
	}
	}

By default the fuzzer initializes slice fields with a maximum length of 10, but multi-value slice constructors for block roots, state roots and randao mixes always use slices with the length equal to the one defined in fieldparams, padding the input slices if necessary. Because of this large slices are allocated in every iteration of the test, and because the beacon state keeps a reference to the multi-value slice, the multi-value slice is not garbage collected fast enough during fuzzing.

To fix this, I wrote a helper function FreeMemory that calls debug.FreeOSMemory() every 10 loop iterations. Each test that fuzzes a proto beacon state and initializes a native state from that proto state inside the loop should call this function. This will significantly reduce in-use memory (usually more than 100x) while still keeping tests times relatively short (out of all existing such tests the longest one took 11 seconds on my machine).

• I have read CONTRIBUTING.md.
• I have included a uniquely named changelog fragment file.
• I have added a description to this PR with sufficient context for reviewers to understand this PR.