Fix potential deadlock during process fork

[vickenty]

What does this PR do?

Fix a potential deadlock in post_fork().

Description of the Change

close_socket acquires _socket_lock, and calling it with the lock held deadlocks.

On top of this the warning did not prove very useful, as it would also trigger when the application is sending metrics from another thread when the process forks, in which case the warning is a bit misleading.

Without the warning there is no reason to check for socket being open, so just silently call close_socket() after the fork to avoid sharing the file descriptor between processes if another thread re-opened it between pre_fork() and fork itself.

Alternate Designs

Possible Drawbacks

Verification Process

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

• [ ] Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
• [ ] PR title must be written as a CHANGELOG entry (see why)
• [ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• [ ] PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
• [ ] PR should not have do-not-merge/ label attached.
• [ ] If Applicable, issue must have kind/ and severity/ labels attached at least.

[aweldy2]

+1 to this being a pretty major issue -- we encountered this exact bug earlier this week. @vickenty another option would be to change socket_lock to be a threading.RLock instead of a threading.Lock so that it's reentrant.