Make Mapgen (mostly) work multithreaded again

[sfan5]

DO NOT SQUASH WHEN MERGING

Problem: The objects managed by BiomeManager, OreManager, DecorationManager and SchematicManager are not thread-safe at all, because:

• ore generation code caches noise as a member variable
• schematic may change loaded schematic data for rotation during placing
• many more

Solution: Create a copy of the managers for each mapgen thread, the implementation of the objects can then freely modify its member variables.

-- Why not teach the implementation to be thread-safe then?
This is unfortunately not as easy and likely requires a larger refactoring*. You can't just e.g. mark the member variables thread_local. So instead I opted for creating a copy of everything, which is guaranteed to work fine with the current code.
The whole thing is misdesigned anyway, it mixes the ore/deco/... settings (which could easy be constant and shared between all mapgens) with mutable implementation details such as cached noise buffers.

* ObjDefManager is also not const correct at all, you can receive mutable references from a const ObjDefManager&. This PR does not fix that.

Consequences

fixes #8300
It is possible to safely run with num_emerge_threads > 1 again, though doing so raises the probability of the following appearing again:

The infamous y=48 bug (#1755, #5125) [mgv7, reproducible 100% with num_emerge_threads = 12 here]

General decoration weirdness on chunk boundaries(?)

With more sane thread values (e.g. num_emerge_threads = 2), these issues are exceedingly rare. So perhaps multiple emerge threads can be enabled by default again soon.

How to test

Test everything related to mapgen, including:

• Custom biome mods (in particular ones that overwrite biomes)
• Using Lua mapgens
• Any mapgen-related Lua API functions
• test with num_emerge_threads > 1

[sfan5]

The general thread unsafeness (in this case: race condition for noise creation) has been present since the very first implementation(s): dcbb953#diff-b4aa9def38b10274e96fd012895653f9R248
The particular crash in #8300 though is caused by 5c1edc5 which adds code that swaps out the noise at runtime.

[nerzhul]

nice to see you are working on mutithread fixes

[paramat]

The infamous y=48 bug (#1755, #5125)

#1755 is mgv6 only, and is not related to threads at all, that is simply the result of how mgv6 is coded to be incompatible with crossing a mapchunk border. For example the mudflow feature alone disallows crossing a mapchunk border.
#5125 is mgvalleys only, and is no longer valid as that was old mgvalleys code which was a horrible mess, a bug at y = 47/48 was not surprising and probably not related to threads. The bug was fixed but i also then completely rewrote the mapgen later.

However i accept that generally there may be some weirdness at mapchunk borders and overlapping areas with multiple emerge threads.

The code changes in this PR are mostly far beyond my understanding, being code architecture stuff, so i am not qualified approve the code changes, but i can test.

[paramat]

Looked through the changes, no objections to what you are doing here.

[sfan5]

However i accept that generally there may be some weirdness at mapchunk borders and overlapping areas with multiple emerge threads.

Right. Any chance you could look into why this happens with mgv7 at some point?
As someone unfamiliar with the mapgen code I'd guess it's a problem with overgeneration (since the area the mapgen works on is one mapblock larger in each direction than the actually requested mapchunk).

[tuedel]

Probably related: #5618 #9357

[paramat]

Ah i did not see the above image earlier, Github was acting strange and not loading some images.

I'd guess it's a problem with overgeneration (since the area the mapgen works on is one mapblock larger in each direction than the actually requested mapchunk).

Yes exactly that. All the other non-mgv6 mapgens overgenerate 1 up, 1 down too, do they also do this?
However, only mgv7 has a river generation loop that runs after the main generation loop, which might complicate things, i am intending to move the river generation code into the main generation loop, see #7878
The bug in the screenshot above was reported in #9357 so may not be caused by this PR?

It is possible to safely run with num_emerge_threads > 1 again, though doing so raises the probability of the following appearing again:

To clarify, are you saying that this PR increases the chances of weirdness with multiple emerge threads, relative to before? Or are you saying the old weirdnesses will just be experienced again?

[sfan5]

The bug in the screenshot above was reported in #9357 so may not be caused by this PR?

Yes, these are existing bugs. This PR just allows you to "experience" them again since num_emerge_threads > 1 caused crashes before.

To clarify, are you saying that this PR increases the chances of weirdness with multiple emerge threads, relative to before? Or are you saying the old weirdnesses will just be experienced again?

The latter. From my testing it looks like the more emerge threads you use, the higher the likeliness of these bugs reappearing anywhere in the world.

[nerzhul]

At least the crash is fixed, for the emerge part i may work on it after this PR is merged to rewrite the emerge workflow which is quite fine but not so easy to understand.