feat: crashpad_wait_for_upload Windows support

[supervacuus]

Required crashpad changes: getsentry/crashpad#126

• Update user docs: feat(native): reflect windows support for crashpad-wait-for-upload in… sentry-docs#13863
• Update backend tradeoff: feat(native): reflect windows support for crashpad-wait-for-upload in… sentry-docs#13865
• Update container env: feat(native): reflect windows support for crashpad-wait-for-upload in… sentry-docs#13864
• Provide instructions for reproduction
• Maybe integrate in CI

---

Steps to reproduce:

• Set up Docker for Windows so you can run Windows containers (follow these steps)
• Verify that everything worked by running a test container. If you use the nanoserver, as suggested, you will be able to reuse it below.
• Build the Native SDK on the host system as a static build with static runtime libraries. This is extremely helpful when deploying to a minimal image, such as nanoserver, given the relatively complex SDK and runtime dependency chain.

  cmake -B build -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DSENTRY_BUILD_SHARED_LIBS=OFF -DSENTRY_BUILD_RUNTIMESTATIC=ON
  cmake --build .\build\ --config=RelWithDebInfo
  
• ensure that the crashpad_handler (and maybe the WER module) are colocated with the sentry_example.exe

  cp .\build\crashpad_build\handler\RelWithDebInfo\crashpad_handler.exe .\build\RelWithDebInfo\.
  cp .\build\crashpad_build\handler\RelWithDebInfo\crashpad_wer.dll .\build\RelWithDebInfo\.
  
• Run the sentry_example.exe with logging inside a nanoserver container only to verify the setup:

  docker run --rm -it -e SENTRY_DSN="YOUR_TEST_DSN" -v C:\host\path\to\your\build:C:\native_build mcr.microsoft.com/windows/nanoserver:ltsc2022 C:\native_build\RelWithDebInfo\sentry_example.exe log
  
• Run the sentry_example.exe inside a nanoserver container to crash (this will typically fail to report):

  docker run --rm -it -e SENTRY_DSN="YOUR_TEST_DSN" -v C:\host\path\to\your\build:C:\native_build mcr.microsoft.com/windows/nanoserver:ltsc2022 C:\native_build\RelWithDebInfo\sentry_example.exe log crash
  
• Run the sentry_example.exe inside a nanoserver container to crash, but with wait-for-upload enabled (this should always report):

  docker run --rm -it -e SENTRY_DSN="YOUR_TEST_DSN" -v C:\host\path\to\your\build:C:\native_build mcr.microsoft.com/windows/nanoserver:ltsc2022 C:\native_build\RelWithDebInfo\sentry_example.exe log crash crashpad-wait-for-upload
  

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against d6ae15a

[JoshuaMoelans]

LGTM, just like the original Linux implementation testing in CI is probably equally tricky, so maybe we should also provide instructions to locally test this?

Also, the backend tradeoff and container environment docs should be updated to no longer limit the wait_for_upload option to Linux only.

[supervacuus]

LGTM, just like the original Linux implementation testing in CI is probably equally tricky, so maybe we should also provide instructions to locally test this?

Also, the backend tradeoff and container environment docs should be updated to no longer limit the wait_for_upload option to Linux only.

These are all great points, @JoshuaMoelans. There is no need to rush this out; we should do all of those, but I primarily wanted this to be "out" and working. Now, we also need to ensure documentation and reproducibility.

[JanFellner]

Don´t want to put pressure or hurry... but is there a rough schedule when this will get merged?
I simply have no clue how this is handled from you from the maintainer side
Waiting for positive feedback on the PR? Anything i could do to help?
(Would not want to use an code from an open PR as basis in my products ;])

[supervacuus]

Don´t want to put pressure or hurry... but is there a rough schedule when this will get merged?

I think we can release this by the end of next week, maybe the week after that. This is a topic that was only very recently raised and came to fruition quicker than expected, as the entire topic of Windows containers in the context of the Native SDK isn't even internally prioritized or supported. Evaluating this also started before you began the discussion; that was primarily a coincidence.

I simply have no clue how this is handled from you from the maintainer side
Waiting for positive feedback on the PR?

We typically don't wait for feedback from users unless we have fixed a problem for a particular user. The issue is that there are currently way higher-priority tasks that we must address first. I was also unsure from the discussion whether you actually encountered the problem that wait_for_upload tries to address, since you asked a more general question.

So, in short, you won't have to base your product on this PR, but I can't promise exact timelines. However, you can test the changes in your test containers to see if they work for you. This would undoubtedly be valuable feedback, at least if they don't work without these changes.

[supervacuus]

@JanFellner, this was released as part of 0.9.0.