[Malleability] Fix root interfaces implementations under stdmap package

[UlyanaAndrukhiv]

Close: #7075

Notes

While working on this refactor, I noticed that some of these memory pools (BlockByCollections, Blocks, ChunkDataPacks, Collections, Results, and Queues) are not currently used. However, I am not certain if they can be removed.

Context

This PR updates the stdmap package to align with the new structure of BackData and Backend for improved memory pool management. The following components have been refactored :

• Assignments
• BlockByCollections
• Blocks
• ChunkDataPacks
• ChunkRequests
• ChunkStatuses
• Collections
• Guarantees
• IdentifierMap
• IncorporatedResultSeals
• PendingReceipts
• Queues
• Receipts
• Results
• Times
• TransactionTimings
• Transactions

Additionally, all relevant tests have been updated to reflect these changes and pass successfully.

[durkmurder]

Finished first round, will take another pass after addressing the comments

[durkmurder]

Good job ⭐

[jordanschalm]

Very nice work on this 👏

Feedback falls mainly into two categories:

1. updating documentation and naming to avoid confusion about what key is used in a mempool
2. removing type-specific methods which are no longer needed with generics

The second category is largely additive to what you have already done, so feel free to create a separate PR if it's easier. Also, if addressing these comments is more complicated than removing code and renaming methods, and is taking substantial time, feel free to skip them.

[jordanschalm]

This Assignments type largely existed to create a type-safe wrapper (for flow.Assignment) around the general-purpose mempool which operated on Entity-typed values. Now that we have made the Backend generic, I believe we can remove the majority of the boilerplate code in the type-specific mempools.

Simplifying type-specific mempool implementations (using Assignments as example)

We can redefine Assignments minimally as:

package stdmap

// Assignments implements the chunk assignment memory pool.
type Assignments struct {
	*Backend[flow.Identifier, *chunkmodels.Assignment]
}

// NewAssignments creates a new memory pool for Assignments.
func NewAssignments(limit uint) (*Assignments, error) {
	return &Assignments{NewBackend(WithLimit[flow.Identifier, *chunkmodels.Assignment](limit))}, nil
}

Assignments has no other specific functionality. All of its existing methods simply delegate to the Backend. Since Backend is embedded, we can remove all methods defined on Assignments (complete implementation is the code snippet above).

Updating interfaces

Currently stdmap.Assignments implements the mempool.Assignments interface. That interface has a few inconsistencies compared to the generic Backend:

• Getter is named ByID rather than Get (1 usage per my IDE)
• All method returns a list rather than a map (0 usages per my IDE)

We can create a generic interface to correspond to the generic implementation:

package mempool

// documentation omitted but should be copied from Backend
type Mempool[K comparable, V any] interface {
	Has(K) bool
	Get(K) (V, bool)
	Add(K, V) bool
	Size() uint
	All() map[K]V
}

Then define the type-specific interface:

package mempool

type Assignments Mempool[flow.Identifier, *chunkmodels.Assignment]

Summary and Suggested Changes

For type-specific mempools where the implementation has few or no differences compared to the generic Backend, I think it is worthwhile to remove the boilerplate code as suggested above. I suspect most mempools will be like Assignments a basically be type-conversion wrappers around Backend.

[jordanschalm]

There is a lot of custom logic here, but we can remove the pass-through methods (eg. Remove, Size)

[jordanschalm]

Similar case to stdmap.Approvals.

[jordanschalm]

Similar case to stdmap.Approvals.