ci: Reduce hangdump timeout

[Youssef1313]

45 minutes looks unnecessarily too high. I wouldn't expect a test to take more than 10 minutes.
Using a lower timeout ensures that there is enough time for producing the dump, before everything is killed by Azure if the job itself times out.
Also, this ensures that the job finishes early and not waste CI machine time when it's likely to never progress further.

Also uses .dmp extension for dump file, as .dmp is openable by VS.

[unodevops]

🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-19848/index.html

[unodevops]

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-19848/index.html

[unodevops]

⚠️⚠️ The build 159936 has failed on Uno.UI - CI.

[jeromelaban]

@Youssef1313 thanks for trying it out. Indeed its dumping at the timeout, but it's continuing anyways:

https://dev.azure.com/uno-platform/Uno%20Platform/_build/results?buildId=159936&view=logs&j=5840de2a-2ff2-59f0-d858-a36dd46deb33&t=3d354f9d-8921-5f2f-eb31-d283d74003be&l=6285

[Youssef1313]

Few notes:

1. The CI logs are showing the following:

   Hang dump timeout of '00:10:00' expired
   Creating dump file '/Users/runner/work/1/s/build/hang.dmp'
   

   First is coming from here and second is from here.

   That means https://github.com/microsoft/testfx/blob/45e52af889d12fbe45f28b75850fd635ccfbe54b/src/Platform/Microsoft.Testing.Extensions.HangDump/HangDumpProcessLifetimeHandler.cs#L331 was false which is very interesting.

2. The process was able to actually progress after the timeout and start continuing more tests. But then it hangs for real, this time without a dump. But this is not expected to happen as we do kill the process after capturing the dump. So I highly think that there was an exception while capturing the dump? I think the common thing when running on MacOS is low disk space which causes the dump to fail to be written on disk. But we should also clearly print any exceptions.

[jeromelaban]

I think the common thing when running on MacOS is low disk space which causes the dump to fail to be written on disk. But we should also clearly print any exceptions

I'd tend to think space is not an issue here, since at the end of a build we're capturing device logs with are very large. Still, we could df -h to be sure.

[Youssef1313]

@jeromelaban I'll try to root it down. It may take a bit of time though