Fixes T8198. Currently, if the policy.locked configuration setting includes a value which is a user PHID, we may perform a cache fill during setup as a side effect of validating it.

Right now, there is no WriteGuard active during setup, because we don't have a Request object yet so we can't actually perform CSRF validation.

Two possible approaches are:

1. Prevent the write from occuring.
2. Change the code to allow the write.

In the past, I think we've hit similar cases and done (1). However, IIRC those writes were sketchier, more isolated, and easy to remove (I think there was one with PKCS8 keys). This one is pretty legit and not very easy to remove without making a bit of a mess.

There's no techncial reason we can't do (2), we just have to create a no-op WriteGuard for the setup phase.

• To reproduce this issue: set some value in policy.locked to a user PHID, then wipe out profile caches in the database, then restart the webserver.
• Reproduced the issue.
• Added the new dummy write guard, fixed a minor issue with disposal semantics (see D12841).
• Verified this fixed the issue.
• Added a throw to the real CSRF validator and performed a real write. Verified I got CSRF-blocked.
• Removed a CSRF token from a form and double-checked that CSRF protection still works.