Optimize controller handler validation

[MRMDevStudios]

Summary

This PR fixes a performance issue in controller handler validation that becomes severe on large Functional Storage networks.

ControllerInventoryHandler currently validates that a selector's backing handler is still connected using:

getItemHandlers().contains(selector.handler)

Because getItemHandlers() is an ordered list, this performs a linear scan of all connected handlers every time the validation runs.

This PR keeps the existing ordered handler list intact and adds a derived HashSet<IItemHandler> for constant-time membership validation.

No separate issue was opened for this bug, so the reproduction details and profiling results are included below.

Issue

On large Storage Controller networks, external inventory automation can cause extremely large server tick stalls when interacting with the controller or a Controller Access Point.

The problem occurs because controller inventory operations may be called repeatedly across many exposed slots, while each individual operation performs a linear handler membership check.

The problematic validation is used by:

• getStackInSlot(...)
• insertItem(...)
• extractItem(...)

Each operation currently checks:

getDrawers().getItemHandlers().contains(selector.handler)

For a controller with hundreds of connected handlers, this means every slot operation can scan the entire handler list.

When another inventory system iterates through many controller slots during insertion, the effective cost becomes approximately:

number of exposed slots × number of connected handlers

This becomes particularly expensive for large networks and for insertion attempts where the matching destination is late in the slot ordering, the storage is full, or the item cannot be inserted.

Observed case

This was identified on a Minecraft 1.21.1 NeoForge server running:

• Functional Storage 1.5.8
• Ender IO 8.2.11-beta

The affected Functional Storage network contained roughly 420 item handlers and exposed roughly 1,500 controller slots.

A Spark profile of ticks exceeding 120 ms showed the following hot path:

EnderIO ConduitNetworkSavedData.onLevelTick
→ ItemConduitTicker.tickNetwork
→ ItemConduitTicker.tickChannel
→ NeoForge ItemHandlerHelper.insertItem
→ FunctionalStorage ControllerInventoryHandler.insertItem
→ java.util.ArrayList.contains
→ java.util.ArrayList.indexOf
→ java.util.ArrayList.indexOfRange