Optimize client light update processing

Changelog.md

@@ -10,6 +10,7 @@ and this project follows the [Ragnarök Versioning Convention](https://github.co
 ### Changed
 
 - `DeduplicatedLongQueue` now creates a new deduplication set instead of clearing it
+- Client light processing now uses a queue which improves performance of light updates
 
 ### Fixed
 

src/main/java/dev/redstudio/alfheim/mixin/client/RenderGlobalMixin.java

@@ -12,8 +12,7 @@
 import org.spongepowered.asm.mixin.injection.At;
 import org.spongepowered.asm.mixin.injection.Redirect;
 
-import java.util.Iterator;
-import java.util.Set;
+import java.util.*;
 
 import static dev.redstudio.alfheim.Alfheim.IS_NOTHIRIUM_LOADED;
 import static dev.redstudio.alfheim.Alfheim.IS_VINTAGIUM_LOADED;
@@ -56,28 +55,15 @@ private boolean disableVanillaLightUpdates(final Set<BlockPos> instance) {
         if (setLightUpdates.isEmpty() || (!IS_NOTHIRIUM_LOADED && !IS_VINTAGIUM_LOADED && renderDispatcher.hasNoFreeRenderBuilders()))
             return;
 
-        final Iterator<BlockPos> iterator = setLightUpdates.iterator();
-        final float lightUpdateLimit = 2048 + ((float) setLightUpdates.size() / 4); // Todo: Rework this once again, this is currently pretty dumb.
-                                                                                    //       It fixed the issue where the FPS on lower end hardware would plummet for a few seconds.
-                                                                                    //       But it also reduced how smooth the frame rate was on higher end hardware.
-                                                                                    //       Updating blocks is costly and will take a long time, this is why lower end hardware plummets for a few seconds.
-                                                                                    //       Higher end hardware instead has somewhat of a FPS "buffer" which can handle it fine over multiple frames thus reducing frame-time spikes.
-                                                                                    //       The technically the best way to do this (that I hadn't though of before) was to add current "FPS" to the equation.
-                                                                                    //       If the FPS is low more updates would be done in one frame if it is high we can afford spreading light updates over multiple frames.
-
-        short lightUpdatesProcessed = 0;
-        while (iterator.hasNext() && lightUpdatesProcessed < lightUpdateLimit) {
-            final BlockPos blockpos = iterator.next();
-
-            iterator.remove();
+        final Queue<BlockPos> queue = new ArrayDeque<>(setLightUpdates);
+        BlockPos blockpos;
 
+        while ((blockpos = queue.poll()) != null) {
             final int x = blockpos.getX();
             final int y = blockpos.getY();
             final int z = blockpos.getZ();
 
             markBlocksForUpdate(x - 1, y - 1, z - 1, x + 1, y + 1, z + 1, false);
-
-            lightUpdatesProcessed++;
         }
     }
 }