This fixes Battle.net error displaying error when running initial setup (which also prevents auto start of Battle.net after install but then installed Battle.net still works).
This is related to the same Battle.net ephemeral certificate added to root store, but now that hits yet a different issue during initial setup. CertGetCertificateChain() is using cached chain engines in Wine which has root store open only once when CertGetCertificateChain() is first called with this engine. Thus, if root store is updated after CertGetCertificateChain() was once called that update won't be seen in the consequently called CertGetCertificateChain() in the same process. Battle.net setup seems to always add the certificate before checking that it works with CertGetCertificateChain() but depending probably on some timing or else factors another CertGetCertificateChain() may be called before that on a different thread which "latches" root store cache in the state before the cert in question is added. I didn't debug why it wasn't happening before or what this sequence depends on because CertGetCertificateChain() should obviously use up to date root store (that is also confir med by the included test).
Patches "crypt32: Lock store in MemStore_deleteContext().", "crypt32: Do not temporary delete contexts in I_CertUpdateStore()." should ensure that we can safely update registry stores in the cached engines without additional locking while those may be concurrently used in CertGetCertificateChain() from another thread. The access to underlying mem store is synchronized, and updating or deleting certificate from I_CertUpdateStore should not be breaking existing in-progress enumerations after 489d95d3bb48e6febc8b1ee6fbbe1d7ed0181ace . Before "crypt32: Do not temporary delete contexts in I_CertUpdateStore()." temporary deletion could fail racing CertGetCertificateChain as some existing certs could be gone missing. While if we delete only what we need to delete and update those with need to be updated or added the concurrent enumeration should behave correctly.
Without "crypt32: Only sync registry store if registry has changed." adding CertControlStore(..., CERT_STORE_CTRL_RESYNC, ...); to get_chain_engine() would be as good as just getting rid of the cache (which is probably there for reasons; reading and de-serializing all the certs from registry takes a lot of time).
The remaining todo_wine in test is for the case when CertGetCertificateChain() is called after cert was added to root store but before that store was explicitly flushed or closed. It seems like that behaves differently on Windows and probably writes to registry right away without waiting for explicit flush on close, but this looks unrelated to the issue and patches concerned here.