frontend: Duplicate browser cookies when profile is duplicated

[WizardCM]

Description

Regenerate Cookie ID and copy existing cookies into a new folder when duplicating a profile.

Without this change, cookies are reused across profiles, so logging out of one logs out of both. This causes very unpredictable behaviour.

Motivation and Context

• Fix regression introduced by UI: Implement backend work for configurable storage locations for settings, profiles, and scene collections #11055

Reproduction Steps:

1. Login via OAuth into a Twitch account
2. Notice all OAuth docks work and config\obs-studio\plugin_config\obs-browser\obs_profile_cookies contains 1 directory.
3. Duplicate Profile
4. Close OBS
5. Notice config\obs-studio\plugin_config\obs-browser\obs_profile_cookies didn't gain a second directory.
6. Close OBS
7. Notice the new and old profile's basic.ini have the same [Panels] CookieId

How Has This Been Tested?

1. Create a Profile named CopyCookies1
2. Login to OAuth via Twitch
3. Duplicate Profile named CopyCookies2
4. Close OBS
5. Verify a new obs_profile_cookies subdirectory was created that matches the value in CopyCookies2's basic.ini and that the [Twitch] section remains identical in both.
6. Re-open OBS, notice Twitch docks correctly work

Tested on Windows 10.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I have read the contributing document.
• My code has been run through clang-format.
• My code follows the project's style guidelines
• My code is not on the master branch.
• My code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[PatTheMav]

My first gut reaction is that the call to DuplicateCookieProfile should probably be done within ActivateProfile, as that function currently takes care of re-initialising docks, authentication profiles, etc. after swapping the global "config".

Placing it after ActivateProfile is correct insofar as you can assume that the new profile has been loaded and replaced global state, but semantically I feel the call is well placed within the activation function.

[WizardCM]

Yeah, the more I've been thinking about this, the more I agree it needs to be part of ActivateProfile. Ultimately, the current implementation won't do what we need it to.

Based on my understanding so far, there's one major flaw with the current implementation:
When the switchover happens, it's still using the old cookie directory until next OBS restart.
So if a user duplicates the profile, then signs out of the second profile, they'd actually be signing out of the first one.

I think the flow has to be

1. Save the profile (we don't currently do this afaik, and I saw you and Warchamp discussing this in another PR)
2. Duplicate the profile files (or write the current config to the new directory)
3. Unload the profile (I tried switching from QDir to std::filesystem but it would fail because the cookies were in use, so I expect it's only partially copying stuff at the moment)
4. Copy the cookies into a new directory
5. Prepare the new profile with the new CookieId in the same way we set the new name
6. Load the new profile, including re-initalising Auth with the new CookieId

I'm unsure if keeping a separate DuplicateCookieProfile is viable due to how interconnected the switchover has to be.. I'll experiment later this week.

[PatTheMav]

One thing that just occurred to me (but haven't researched this) is that ActivateProfile would need to know it has to "fix up" the profile it currently activates (by calling DuplicateCookieProfile) but that's context information not available to that call (and just adding a duplicate = true argument feels smelly to me).

So just calling it when the code is actively duplicating a profile (and where it has that context information) is a good-enough solution if you're still comfortable with it as well.

Maybe just add a task issue and note it with a ToDo here so we don't loose track of this cleanup/refactoring task maybe.