[no squash] Fix two common causes of "app isn't responding"

[grorp]

• Server startup and shutdown block the main thread.
  -> Solution: Server startup and shutdown have been moved to separate threads

• Loading of cached media blocks the main thread because all cached media is loaded at once.
  -> Solution: Loading of cached media is now done in chunks.
  (Loading of non-cached media is already unproblematic.)

See #14440

To do

This PR is a Ready for Review.

Note: I have only tested this on Linux so far. It still needs to be tested on Android.

How to test

Start a singleplayer session with a heavy game (e.g. MeseCraft or MineClone 2). Verify that the main thread is not blocked in the "Creating server..." and "Media..." phases, e.g. by resizing the window, pressing ESC, trying to close the window, ...

Verify that the main thread is not blocked in the "Shutting down..." phase

Verify that loading of cached media isn't noticeably slower. (Obviously it'll be a bit slower since we're now drawing frames / handling events in-between media loading, but it shouldn't be noticeably slower.)
↑ Please actually test this. ↑

[grorp]

Loading of cached media is now done in chunks.

Even though I've already set a rather large chunk size, loading of cached media is still about 100ms slower than before on the Capture the Flag server, and I haven't quite figured out where that time is being spent.

EDIT: This should be fixed by the latest commits.

[sfan5]

Pulling the load screen drawing into here feels like an abstraction violation. But I have an idea to improve this and will do it after this PR.

[grorp]

I tested my changes with ThreadSanitizer. It output countless of unrelated "data race" errors which are already present on master, but I found two warnings related to this PR that occur while shutting down:

ThreadSanitizer: data race (/mt/bin/minetest+0x55ca93) (BuildId: d5bfc2de556551e34bade641abe56a1f299abce2) in operator delete(void*)
ThreadSanitizer: data race /mt/src/settings.cpp:64:7 in SettingsHierarchy::getParent(int) const

tsan.txt

I think these are caused by the following situation:

• FpsControl reads from g_settings on the main thread
• Server::~Server deletes m_game_settings (calling g_settings->onLayerRemoved) on ServerStopThread

As far as I can see, fixing this problem would require implementing synchronization for g_settings, which I consider out of scope for this PR.

[sfan5]

fyi I opened grorp#11

[sfan5]

Verify that loading of cached media isn't noticeably slower. (Obviously it'll be a bit slower since we're now drawing frames / handling events in-between media loading, but it shouldn't be noticeably slower.)
↑ Please actually test this. ↑

By the way, my results for this are 159ms (before) and 154ms (after). So not significant at all.

[grorp]

By the way, my results for this are 159ms (before) and 154ms (after). So not significant at all.

Thanks for testing, that's good. I had a big mistake in my measurement setup, even the old version wasn't as slow as I thought.