fix: add erasure reDecoder for evicted chunks

[nugaon]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

During long-lived joiner operations, reconstructed chunks can be evicted from the local cache due to memory pressure. When these chunks are needed again, the current implementation doesn't attempt to recover them a second time. Instead, it falls back to direct network fetching, which fails with ErrNotFound if the chunk isn't available in the network.

This creates a reliability issue where successfully recovered chunks become inaccessible once evicted from cache, potentially breaking long-running operations like downloads or uploads of large files.

This PR implements a erasure redecoder functionality with the following components:

• ReDecoder: A new wrapper that attempts network fetch first, and only falls back to erasure recovery if the network fetch fails with ErrNotFound.
• Lazy Decoder Instantiation: Recovery decoders are only created on-demand when network fetch fails, saving resources.
• Memory-Efficient Caching: Maintains the existing memory optimization of nulling decoders after successful recovery while keeping track of successful recoveries.

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

Screenshots (if appropriate):

[martinconic]

I think here it is possible to have a deadlock. At this point, the same goroutine is holding the lock from line 96 and trying to acquire it again here in decoderCallback.

[nugaon]

decoderCallback is called in prefetch function only that is executed by a different go routine

[martinconic]

Is there a way to manually test this?

[nugaon]

Is there a way to manually test this?

The erasure data recovery should be triggered, for example, by leaving out some chunks for upload of an erasure coded chunk tree similarly as beekeeper does. Then, attempt to retrieve the data and see what happens in case of a Bee which does not include the changes and the one which has it. The bee instances should be started with lowered size cache parameters e.g. --cache-capacity=1.