Previously an UnhandledException would be thrown and the stack trace / message would be printed to System.err in the default UncaughtExceptionHandler for ThreadGroup. This was undesirable as it meant that logging frameworks / exception monitors such as Sentry were unable to get the exception. Additionally it would cause the death of the thread in the ExecutorService. This change mimics the behaviour of exceptions occuring during synchronous tasks.
https://bugs.mojang.com/browse/MC-100524
Log files were previously overwritten when more than 7 were created on the same day. This is caused by Log4J's default behavior with DefaultRolloverStrategy, which defaults to a max of 7.
While a max of 1000 doesn't fully stop this problem from happening, for 1000 log files in a single day to be reached the server would have to restart faster than once every 1.5 minutes, which is unlikely to happen. So 1000 seems like a good limit. A higher max isn't used because when it gets higher, there are performance hits due to the way Log4J checks for the next file.
Clean up implementation and firing of both of these events by routing
both unload and load behaviors to consistent method calls.
This fixes issues where a few places would not call Load or Unload events
when it should have.
Additionally, reduces diff by moving the neighbor marking code into these
consistent points.
Additional benefits of the change include improving the neighbor marking
methods to use getChunkIfLoaded instead of getLoadedChunkAt in some places,
as the latter will cause chunks to be marked active and not unload.
Finally, this also updates CraftWorld.loadChunk to use the new methods, as the
previous logic did not properly handle the new unload queue.
