fix(python apps): fork child + exec appcmd in child to avoid issues

[sicoyle]

Description

Fork is unsafe after threading has been used, at least for python. This is a known issue in the python community. See:

• https://www.python4data.science/en/24.3.0/performance/threading-forking-combined.html#Threading-and-forking-combined
• Forking from background thread python/cpython#80083
• Python 3.7.9 logging/threading/fork hang python/cpython#86263

Forking after threading has been used can cause deadlocks/hangs when using threading primitives like Lock, Condition, or Queue in a process created via fork. All of this occurs within the internals of durabletask-python. This means it will impact any app using the python sdk, be it dapr agents or general python workflows. I tried various python versions and they all experience hangs, at various points due to this.

This PR corrects this by using syscall.ForkExec to fork a child, then execs python or whatever app language within that child so the app language starts via exec, avoiding it knowing about the fork. I will say a downfall of this is I lose the blue APP prefix stuff on the log lines. So this means changing the UX via terminals unfortunately. I tried adding that back with pipes, but then adding the pipes to give me the log prefix then broke my python app again causing the hang.

This is what it looks like btw with this PR. Blue INFO is from the sidecar and the app logs are in white without the ===APP=== prefix that we used to have:

I need to test this on a windows machine to make sure I don't leave zombies, and also I think at this point this is good enough to fix other OS's. I could leave a note in the docs that running python apps on windows could lead to unpredictable behavior for now and create a follow up issue for that. Thoughts?

Issue reference

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[JoshVanL]

@sicoyle tests are very red

[codecov]

Codecov Report

❌ Patch coverage is 0% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 15.49%. Comparing base (9780aab) to head (167668f).
⚠️ Report is 19 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/standalone/run.go	0.00%	9 Missing and 2 partials ⚠️
pkg/standalone/process_group_unix.go	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1580      +/-   ##
==========================================
- Coverage   15.74%   15.49%   -0.25%     
==========================================
  Files          64       64              
  Lines        7090     7204     +114     
==========================================
  Hits         1116     1116              
- Misses       5888     6002     +114     
  Partials       86       86              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JoshVanL]

@sicoyle tests are still unhappy

     utils.go:119: 
        	Error Trace:	D:/a/cli/cli/tests/e2e/standalone/utils.go:119
        	            				D:/a/cli/cli/tests/e2e/standalone/stop_test.go:36
        	Error:      	Received unexpected error:
        	            	exit status 1
        	Test:       	TestStandaloneStop
        	Messages:   	dapr didn't exit cleanly

[acroca]

Why? I don't see how this is better than using daprWindowsOS

[sicoyle]

this exact formatting is already used in a diff file elsewhere so i copy/pasted it here to be usable for me in this area. I did not pick this name. Happy to change, but it did exist this way so I kept for consistency🤷‍♀️