libsteam_api.so forward compat: finish VERSION_SAFE_STEAM_API_INTERFACES implementation

[stevenlafl]

Purpose

This brings InitSafe compatibility with the libsteam_api.so. This should help future-proof as newer libs do not contain symbols for Init().

Approach

Before this patch, VERSION_SAFE_STEAM_API_INTERFACES results in compile time errors and doesn't run.

This adds ifdef checks where Init() is used, replacing them with InitSafe() as was already done in other files. It properly uses, according to the comments, the CSteamAPIContext as stated in rehlds/public/steam/steam_api.h

Open Questions and Pre-Merge TODOs

• Additional longer-term playtesting

Learning

I explored the headers to gain all this information and kept compiling until it worked. I used gdb to runtime errors. At first, I had compile-time type safety errors, which is how I ended up with the (void *) approach in sv_steam3.cpp, which works flawlessly.

[anzz1]

The libsteam_api.so that is packaged with 8684 aka 'steam_legacy' is this one https://github.com/rehlds/ReHLDS/blob/master/rehlds/lib/linux32/libsteam_api.so
If you managed to get the new anniversary DLL instead you updated improperly. This can often happen in steam it is one of its bug when switching branches.
As mentioned in this comment the correct steam_api version for 8684 engine is 1.60.88.17 on windows and the equivalent in linux (shared elfs don't store any version string like winpe format does).
All that is needed is to change the CI so it packages the steam_api.dll and the libsteam_api.so files in the releases.
As in these commands

move rehlds\lib\steam_api.dll publish\bin\win32\steam_api.dll

and

mv rehlds/lib/linux32/libsteam_api.so publish/bin/linux32/libsteam_api.so

that other PR where that comment is posted does that, and would be good to merge if it also didn't do that nonsense with re-signing already-signed files

[anzz1]

And like pointed out in the discussion in that issue #1106 , it's not correct way to proceed to create some from of frankenstein hybrid of the new and old branches.
Both the ReHLDS and its supporting projects like ReGameDLL_CS are reverse-engineered from the old engine the 'legacy' branch.
And the binary is supposed to be matching to the original as you can see all the changes and fixes are #ifdef'd in a REHLDS_FIXES define.
You are simply not supposed to use a different version of steam_api than what is originally designed for. The function signatures change between versions and can lead to undefined behaviour and crashes.
If you look at how steam distribute its games the steam_api DLL is not managed by steam but its distributed part of games files. As in whatever was used for the game when it was compiled that exact version of the API will be shipped and nothing else.
Because sometimes changes are not severe you can indeed get away with using wrong version and it would work just fine until it calls some function that is now in different place in the vtable, which might be never
Its still wrong behaviour and should not be encouraged. It is a feature that ReHLDS doesn't start with a wrong API version it is not designed for.

If you want to make anniversary version of ReHLDS that should be in its own branch and reverse-engineered from the anniversary engine not the legacy one. It seems that very many people are missing this which in my opinion should be obvious, but refer to other decompilation / reverse-engineering projects to understand the problem.

tl;dr; the steam_api.dll and libsteam_api.so must be changed in the CI so they're distributed along with ReHLDS so the correct version is always used

[stevenlafl]

Point taken. I narrowed the scope and clarified the purpose of the PR.