Always try to reinitialize Crypto.Random when forking minion process

[lukasraska]

What does this PR do?

Always try to reinitialize Crypto.Random when processing minion events to avoid issues when minion tries to sign something during/after job execution.

What issues does this PR fix or reference?

Fix #55116

Previous Behavior

When having minion configured with option minion_sign_messages: True, any job result event would fail with PID check failed. RNG must be re-initialized after fork() when using RHEL 6 or TCP transport

New Behavior

Minion successfully responds with job result

Tests written?

No, AFAIK the only way how to really test this is to enable minion_sign_messages for integration tests. As this is currently global for all tests, it might affect other tests that inspect raw events (cc @waynew )

Yes

Commits signed with GPG?

Yes

[lukasraska]

Added tests + rebased to current master (@Ch3LL)

[lukasraska]

Seems like the tests fail on Windows. From the look of it, it might actually be bug in Python (https://bugs.python.org/issue17560), but I have to test it manually on Windows first.

[lukasraska]

I've made one fix for Win test, but they still fail (probably because when the fork happens the current process it so big it triggers either the mentioned bug or something else). But I'm not able to reproduce it on clean Win machine and I don't have access to these testing golden images.

Any ideas how to tackle this? Otherwise I will just add skipIf for Windows.

[waynew]

@s0undt3ch or @twangboy would probably have the most knowledge about this. Could either of you weigh in?

[s0undt3ch]

re-run all full

[s0undt3ch]

re-run full all

[dwoz]

@lukasraska Please address @s0undt3ch's comments as well as the windows test failures.

[lukasraska]

Rebased, implementation changed as _after_fork_methods hook and force-pushed.

@dwoz, @s0undt3ch

[lukasraska]

re-run pr-amazon1-py2
re-run pr-windows2019-py3