Make daemonset mountPropagation configurable, remove bidirectional default

[jlubins]

This PR addresses issues #119 and #154 where the core-dump-handler causes excessive bind mounts due to bidirectional mount propagation. When pods restart frequently (e.g., due to memory limits being set too low), this has potential to create thousands of duplicate bind mounts, leading to:

• High I/O wait times
• Node performance degradation
• Potential node failures

The current implementation hardcodes mountPropagation: Bidirectional in the DaemonSet template. As noted in the Kubernetes documentation (see warning), bidirectional mount propagation can be dangerous and requires containers to properly clean up mounts on termination. Each pod restart doubles the number of mounts, quickly reaching system limits.

This PR makes mountPropagation configurable via Helm values and removes the bidirectional default. Users can now:

• Use the safer default (no mount propagation specified)
• Explicitly set bidirectional mode if needed for their use case
• Choose other propagation modes as appropriate

[jlubins]

Hi @No9, when you have a chance, could I trouble you to review this PR? It has seemingly bitten several users in the past, and prevents me from safely using core-dump-handler in quite a few places.

[No9]

@jlubins the lint is failing - can you update the PR to resolve this and I can merge

[jlubins]

Hey @No9, apologies for the delay. Do I need approval to get the lint test to run again?

With my latest commit, I've fixed the Python version issue that was causing the workflow to fail:

Run actions/setup-python@v2
Version 3.7 was not found in the local cache
Error: Version 3.7 with arch x64 not found

I updated the version per the README docs for setup-python here. It looks like chart-testing-action accepts any latest minor version. I pinned to 3.13, but I can change it to '3.x' if you'd prefer the workflow to automatically use the latest Python 3 version.