feat: add priorityClassName support for provisioner and helper pods

[dibaro]

Description

This PR adds support for configuring priorityClassName for both the main provisioner pod and helper pods in the local-path-provisioner Helm chart. Previously, users could not set priority classes for these critical storage infrastructure components, limiting their ability to properly prioritize pods in resource-constrained environments.

Changes

• Added priorityClassName field to values.yaml for the main provisioner pod
• Added configmap.helperPod.priorityClassName field to values.yaml for helper pods
• Modified templates/deployment.yaml to conditionally render priorityClassName when specified
• Updated templates/configmap.yaml to make helper pod priority configurable (was hard-coded to system-node-critical)
• Enhanced documentation in README.md with configuration examples and parameter descriptions

Usage Scenarios

• Main pod priority only: Set priorityClassName to assign priority to the main provisioner deployment
• Helper pod priority only: Set configmap.helperPod.priorityClassName to assign priority to volume operation pods
• Both pod priorities: Configure both fields to have different priority classes for different pod types
• No priority classes: Leave both fields empty to maintain current behavior (helper pod defaults to system-node-critical)

Example

# Main provisioner pod priority
priorityClassName: "high-priority"

# Helper pod priority (for volume operations)
configmap:
  helperPod:
    priorityClassName: "system-cluster-critical"

Or via command line:

helm install local-path-storage . \
  --set priorityClassName=high-priority \
  --set configmap.helperPod.priorityClassName=system-cluster-critical

Testing

• Verified that priority classes are correctly applied when specified in values
• Confirmed that no priorityClassName field is rendered when values are empty
• Ensured helper pod maintains system-node-critical default when not overridden
• Tested both individual and combined priority class configurations
• All existing functionality remains backward compatible

Backward Compatibility

This change is fully backward compatible. All existing configurations will continue to work as before, with helper pods maintaining their default system-node-critical priority class when not explicitly configured.

[dibaro]

Hi, this PR introduces support for priorityClassName in provisioner and helper pods, which is essential for managing pod scheduling priorities in Kubernetes clusters. It has been open for some time, and I believe it would be beneficial for the community to have this feature merged. Could you please review and consider merging this PR? Thank you