istio: disable PodDisruptionBudget

[dkoshkin]

What type of PR is this?

Bug

What this PR does/ why we need it:

The default helm chart has the PodDisruptionBudget enabled but the replica count for the different Istio components are set to 1.
This prevents those pods from being drained.

This PR disables PodDisruptionBudget. Rancher have also disabled this.

➜  dkkonvoyistiopdb k get pods -n istio-system
NAME                                     READY   STATUS      RESTARTS   AGE
istio-citadel-84655cbbf6-l29vz           1/1     Running     0          12m
istio-galley-77c656c77-4mpt7             1/1     Running     0          12m
istio-ingressgateway-cdb65885d-6qzcc     1/1     Running     0          12m
istio-init-crd-10-1.4.3-sqwrf            0/1     Completed   0          12m
istio-init-crd-11-1.4.3-cjkxc            0/1     Completed   0          12m
istio-init-crd-14-1.4.3-4nhgv            0/1     Completed   0          12m
istio-pilot-77d84c6675-r8vqp             2/2     Running     0          12m
istio-policy-854c9ddbd4-2fw9f            2/2     Running     1          12m
istio-sidecar-injector-cd9f46979-z67cf   1/1     Running     0          12m
istio-telemetry-7869cf9795-lw4bt         2/2     Running     1          12m
istio-tracing-5d6cdf857c-x4w5s           1/1     Running     0          12m
istiocoredns-7cb74f86cf-qscx9            2/2     Running     0          12m
kiali-66fcf7544-xgkmz                    1/1     Running     0          12m
label-ns-1.4.3-7cthj                     0/1     Completed   0          12m
➜  dkkonvoyistiopdb k get pdb -n istio-system
No resources found in istio-system namespace.

Which issue(s) this PR fixes:

https://jira.d2iq.com/browse/D2IQ-64552

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

Disable Istio PodDisruptionBudget, the default settings and replica count of 1 prevents pods on nodes from being drained.

Checklist

• The commit message explains the changes and why are needed.
• The code builds and passes lint/style checks locally.
• The relevant subset of integration tests pass locally.
• The core changes are covered by tests.
• The documentation is updated where needed.