Make render interval slightly more configurable

[iczero]

It seems that at some point, autosave was changed to be a lot more frequent. According to C2ME:

[generalOptimizations.autoSave]
        # (Default: ENHANCED) Defines how auto save should be handled  
        # VANILLA: Use vanilla auto-save behavior (auto-save performed every tick during ticking)  
        # ENHANCED: Use C2ME enhanced auto-save (auto-save performed when the server have spare time after ticking)  
        # PERIODIC: Use pre-1.18 vanilla auto-save behavior (auto-save performed every 6000 ticks during ticking)  
        #  
        # Please preserve quotes so this config don't break
        # 
        mode = "default"

As a result, by default, it seems that BlueMap will rerender chunks every 5 to 10 seconds. This is currently not configurable. This is useful when the user wants changes to be reflected almost immediately; otherwise, the server effectively wastes cycles rendering chunks that nobody will see, only to render them again 10 seconds later.

This PR adds two configuration options:

• update-region-after-inactivity: Wait for approximately this many seconds of inactivity on the region file before rerendering it.
• update-region-max-inactivity-wait: Approximate max amount of time to wait before rerendering the region anyways.

Setting these to higher values will slow down rendering. This should help on both Vanilla and C2ME servers.

[TBlueF]

I strongly believe, that there is a misunderstanding with what the C2ME config comment means and what this actually means for bluemaps update file-watchers. Having an actual region-file-change every tick, meaning:

• open the file
• serialize the changed in-memory chunks into nbt
• compress the nbt-data
• potentially shift data within the entire region-file to make room for the chunk if the size increased
• write the comprssed data
• close the file

would be a ton of absolutely wasted performance on minecrafts side, i somehow doubt they actually do that :D

I would love to see some testing on this, e.g. a log that logs every time bluemap detected a file-change. If that really shows multiple file-changes on a single region-file within a minute, then we can talk about adding these config-options :)

Also keep in mind that bluemap does more checks before actually rendering anything. A chunk is only updated if its internal timestamp changed -> bluemap won't re-render an entire region-file just because a single chunk changed in it :)

[iczero]

I've run inotifywait -m -r -e modify world/region/, which I (perhaps wrongly) assume is similar to what BlueMap is doing in order to watch for file changes. On both C2ME "enhanced" and vanilla (without C2ME at all), I am getting several "modify" per second on different region files. I haven't yet tested on pre-1.18, but I would assume C2ME is right here.

Also I can confirm that this patch dropped server CPU usage while any players were active significantly. Running /bluemap before this would show that it was constantly updating. The server is on NeoForge on Minecraft 1.21.1.

Edit: Issue was not reproduced by the community. Please comment if you also have this problem.

[TBlueF]

We talked about this on discord, but just to have this documented in the right place :) ...
I am fine with implementing a config for this, but my suggestion would be the following:

Keep the 5 second delay from file-change normally, but add a (configurable) minimum time between re-renders of the same region which defaults to 1 minute.
That way we only have one config value which should be easier to understand, has a sensible default and doesn't unnecessarily delay the map-updates, if events are sparse anyways.

A Cache<Vector2i, Instant> or similar with a value-timeout could be used to implement the "last render time" information storage without having to worry about accumulating old information in memory.

[TBlueF]

Implemented with cde3ba0.
There is now a hidden config in plugin.conf called update-cooldown which defaults to 60 (seconds) and can be changed if needed.