Add thread guard for force_draw and update related documentation

[jsjtxietian]

Closes #79190

[akien-mga]

Is documentation enough to solve #79190, which is a crash? Can we add some thread guards like we have in Node methods, or there's no access to that info from servers? CC @RandomShaper

[jsjtxietian]

I believe we should add a thread guard, should I add it to this pr or make another one ?

[akien-mga]

I think adding a thread guard in this PR too would make sense.

I see examples of it being done this way outside of Nodes (which have their own ERR_MAIN_THREAD_GUARD):

modules/navigation/godot_navigation_server_2d.cpp
186:    ERR_FAIL_COND_MSG(!Thread::is_main_thread(), "The SceneTree can only be parsed on the main thread. Call this function from the main thread or use call_deferred().");

Adding an error message like this would also make sense here, it could be something like:

ERR_FAIL_COND_MSG(!Thread::is_main_thread(), "Manually triggering the draw step from the RenderingServer can only be done on the main thread. Call this function from the main thread or use call_deferred().");

Needs testing to confirm that it works as expected (errors on thread, works on main thread or when using call_deferred()).

[RandomShaper]

I agree with @akien-mga's remarks, but I'd still need clarity on something. Is the compatibility renderer able to run on a thread (rendering/driver/threads/thread_model == RENDER_SEPARATE_THREAD (2))? In that case, it'd still be possible to call any function on any thread. In that case, I'd rather put the thread guards at the Rasterizer*GLES3 level. (For RenderingDevice renderers, the location would be in each RenderingDevice* implementation's function. After the split to RD-RDD happens, threading will be improved with guards, among other things, and I think my points here align with that plan.)

[akien-mga]

If the situation is more complex than it seemed initially, and this might partially be overridden by the RenderingDeviceDriver work, we might want to stick to just adding a note in the docs as done here for 4.2.

[jsjtxietian]

Is the compatibility renderer able to run on a thread (rendering/driver/threads/thread_model == RENDER_SEPARATE_THREAD (2)

Changing thread model to other option will cause crashes too.

Crash log when thread policy is single safe or unsafe:

when thread model is multi thread, there will be error spam and then crash:

[RandomShaper]

Well, then let's just follow @akien-mga's idea, until everything can be addressed better.

[akien-mga]

Looks good to me, unless we foresee that this extra check could have a non-negligible performance impact.

[akien-mga]

Just in case there's a performance impact, I'm deferring this to merge after the 4.2 release, and we can cherry-pick for 4.2.x if we confirm it's a safe approach.

[YuriSizov]

Thanks!

[YuriSizov]

Cherry-picked for 4.2.2.