Option to disable cookie database locking

[Aven-dev]

Solving issue: https://feedback.secondlife.com/web-bugs/p/search-asks-me-to-accept-cookies-each-time-i-launch-client

Chrome 114 added a security measure for Windows systems that prevents malware from stealing cookie or session information, by maintaining a file lock on the corresponding database files.

This security measure is not good for applications like SecondLife that spawn multiple Dullahan processes per instance per profile. Cookies are not remembered between Dullahan sessions, prompting users with cookie walls and logged out sessions every single time.

This pull request disables that security measure by default, to restore it to pre-Chrome 114 behavior, and adds to option to restore the security measure by setting disable_cookie_database_locking = false in the CEF settings.

[Aven-dev]

@callumlinden I'm only able to build this project against CEF 112 on Windows, but my current viewer Firestorm uses CEF 118. Building against any other version leads to override signature mismatches. Is this project now being maintained elsewhere?

If so, LockProfileCookieDatabase needs to be added to disable-features in order to fix the reported issue (as I tried with this PR), or viewers needs to close the Dullahan instance that gets opened for the user's profile (not the "undefined" one) right after login. After spawning in-world I didn't observe the PID of that instance doing any file operations with ProcMon, so it should be safe to.

[Aven-dev]

Tested against the latest commit and CEF 138 and working.

It won't magically fix the issue that SecondLife has. They will have to update the command line when spawning Dullahan processes from --disable-features=AudioServiceOutOfProcess to --disable-features=AudioServiceOutOfProcess,LockProfileCookieDatabase. That also means SecondLife doesn't need this patch.

When exploring the code base I spotted another issue: in dullahan_impl_windows.cpp there is the code command_line->AppendSwitchWithValue("disable-features", "AudioServiceOutOfProcess");. This won't do as dullahan_impl::OnBeforeCommandLineProcessing can already write the "disable-features" parameter, and only one may exist (last specified wins). Values have to be merged.

// Features can be explicitly forced on or off by specifying a list of comma-
// separated feature names via the following command-line flags:
//
//   --enable-features=Feature5,Feature7
//   --disable-features=Feature1,Feature2,Feature3

source