Fix global scripts not being added because of bad global_script_class_cache.cfg

[amarsero]

Fixes #102557, probably also fixes #102568

The Issue:
A commit made "is_tool" and "is_abstract" mandatory to add new global classes to ScriptServer::global_classes. But global_script_class_cache.cfg from projects before 4.4 lack these properties, so these classes won't be added, causing errors when running the game.

Current Solution:
After the editor scans all the scripts for the first time, now forcibly updates global_script_class_cache.cfg, resolving the issue.
However, running a 4.3 game with 4.4 without first opening it with the editor at least once still fails.

I've tried to fix this in ScriptServer::init_languages, where the global classes are first loaded, but couldn't figure it out.

[akien-mga]

Some quick thoughts, but @RandomShaper and @Hilderin should be able to assess this further:

• This seems to remove an optimization (only update when it's need). Would be good to assess whether this will lead to a lot more updates than necessary and possibly a performance impact, or possible side effects of writing an unchanged file to disk too frequently (Windows can be touchy there). If yes, the alternative could be to figure out how to better check whether an update is needed, instead of always updating.
• Another approach could be to make the new is_tool and is_abstract not mandatory, and treat those as false if they're missing. Or a third bool option ("unset") but that would require another variable or changing to an int internally, that's a bit hacky.

I'm not necessarily suggesting to implement any of the above, it's just food for thought. The proposed solution here might totally be the best one already.

[amarsero]

Thanks for the thoughts!

About removing the optimization, i believe the method is called only once at the start of the editor. Only on the first_scan of the EditorFileSystem. So there should be no big performance impact.

And i thought about making them not mandatory, but tool scripts were added on 4.3, so any tool script migrating to 4.4 might break if we default to false.

The problem is not so much the editor, since it refreshes all the scripts at startup, but the games don't work when global_script_class_cache.cfg is bad.

[Hilderin]

After looking at the issue a bit, I found 2 problems.

1. When _first_scan_process_scripts calls _register_global_class_script, the following lines are never called:

ScriptServer::save_global_classes();
EditorNode::get_editor_data().script_class_save_icon_paths();

That causes the global_script_class_cache.cfg to not be saved on first scan. I tested by modifying the _first_scan_process_scripts to return true when a new global script is registered and added the call to these 2 lines when it results true.

2. The most problematic issue is that the UIDUpgradeTool::get_singleton()->finish_upgrade is done before the first scan is done. Since the global cache is invalid and because the first scan was skipped, no global classe are registered during the upgrade process, causing all the scripts processed in the update to be invalid. I fixed that by executing the upgrade after the first scan. Note: I'm kept the scan on upgrade_finished just in case, but I'm pretty sure it's useless since the first scan was already executed and that the upgrade only resaves resources which should trigger the EditorFileSystem to update directly.

Another minor modif: I added a break in EditorFileSystem::_get_global_script_class to prevent looping for nothing.

I created a branch with my modified test code to help you if you want: master...Hilderin:godot:fix-global-class-names-not-save-with-upgrade-tool

[amarsero]

Thanks for the help Hilderin!

Now if a global class is found or removed on the first scan, global_script_class_cache.cfg is updated.
This is to ensure migrations from earlier versions have all the needed properties.

Also i noticed that every time that EditorData::script_class_save_icon_paths was called, ScriptServer::save_global_classes was called immediately before. And both methods changed and saved global_script_class_cache.cfg. To avoid writing the file twice I took the liberty of unifying both methods into script_class_save_icon_paths (but without modifying save_global_classes).

[RandomShaper]

Notwithstanding other comments needing to be addressed, this makes sense to me.

[KoBeWi]

script_class_save_icon_paths() seems to be called as often as before. Now it updates all class properties, while previously it would load class cache, modify one property of each class and save it too, so not much changed on that regard. We could better optimize class cache saving, but this PR does not make it worse.

[Hilderin]

Tested locally, it works as expected, fixes the issue and even prevents some potential out of sync of the global cache file on some limit cases or in the future if other props are added. Good job!

[akien-mga]

Thanks a ton! This solves some of the remaining release blockers for 4.4, so that's a huge contribution!