SMFv3 integration

[atampy25]

As title. Updates the existing contracts, unlockables and plugin integration with SMF, and expands it to also cover locations, entrances, agency pickups and campaigns.

Does not work with SMFv2, so shouldn't be merged until SMFv3 release. Also contains breaking changes, including finally removing the mod-checking API that was deprecated years ago.

---

General

• I've run Prettier to format any changed files
• I've verified that my changes work, and included a test plan

---

Testing

• I have added or considered adding unit/integration tests that cover any code changes

[RDIL]

I will relent on letting you have user IDs in these requests but we need it to be at least 1 major version away (i.e. v9) and we need to have a deprecation warning in the v8 series

[grappigegovert]

Why are you propagating the userid everywhere, to then only use it to check the game platform when the platform itself is also in the request jwt?
In fact, a possible issue with this is when a user uses IOI's progression linking, which makes it possible to log into two different platforms with the same userid.

[RDIL]

I had that same question ^^ cc @AnthonyFuller

[grappigegovert]

a possible issue with this is when a user uses IOI's progression linking, which makes it possible to log into two different platforms with the same userid.

I realise now that this is only an issue when both log in at the same time, which is not as likely but still possible I guess.
(Actually, I wonder if IOI allows that on their servers)

[AnthonyFuller]

I believe as part of cross progression, you can now only have one of those linked profiles connected at a given time.
PlayStation has always had this afaik since you can get the PsnMultipleDevices error on PC.

[atampy25]

The main issue logistically in propagating either the user ID or platform through is just whether the JWT is available; the user ID is less disruptive because so many paths already have it as a parameter, and to SMF integration it's all the same. It's also more useful to expose to plugins because user-specific contract logic is a legitimate use-case (and I can think of more that you can do with user-specific contracts than platform-specific contracts)

[grappigegovert]

I think looks good so far, but if we're doing the contracts and campaigns per deployment, we should be doing the unlockables and entrances per deployment too; so maybe change those into a hook/tap system as well.
Actually, at that point we might as well convert the entire 'config' manager to use that.

[grappigegovert]

Something like this maybe in configSwizzleManager

export const configModifierHooks: HookMap<
    SyncHook<
        [
            /** configData */ object,
            /** gameVersion */ string,
            /** userId */ string,
        ]
    >
> = new HookMap(() => new SyncHook())

export function getUserVersionedConfig<T = unknown>(
    configKey: keyof typeof configs,
    gameVersion: GameVersion,
    userId: string,
    clone: boolean = true,
): T {
    const configData = getVersionedConfig(configKey, gameVersion, clone)
    configModifierHooks.for(configKey).call(configData, gameVersion, userId)
    return configData
}