Add UDP endpoints to coturn Helm chart

[sysvinit]

This change adds the port definitions for coturn's UDP control port to the StatefulSet and Service definitions in the Helm chart. While this doesn't introduce any direct functional changes, it ensures that the control plane is aware of the fixed UDP port in use by coturn, which may then be advertised by service discovery glue which announces coturn pods based on the ports they expose.

I've run into difficulties updating prior versions of the coturn Helm chart to the one in this PR, which turns out is a Kubernetes bug. I've added a release notes entry to the changelog with the required manual actions required to perform the upgrade.

This is the UDP half of https://wearezeta.atlassian.net/browse/SQPIT-1018.

Checklist

• The PR Title explains the impact of the change.
• The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
• If this PR changes development workflow or dependencies, they have been A) automated and B) documented under docs/developer/. All efforts have been taken to minimize development setup breakage or slowdown for co-workers.
• If HTTP endpoint paths have been added or renamed, or feature configs have changed, the endpoint / config-flag checklist (see Wire-employee only backend wiki page) has been followed.
• If a cassandra schema migration has been added, I ran make git-add-cassandra-schema to update the cassandra schema documentation.
• changelog.d contains the following bits of information (details):
  • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.
  • If new config options introduced: added usage description under docs/reference/config-options.md
  • If new config options introduced: recommended measures to be taken by on-premise instance operators.
  • If a cassandra schema migration is backwards incompatible (see also these docs), measures to be taken by on-premise instance operators are explained.
  • If a data migration (not schema migration) introduced: measures to be taken by on-premise instance operators.
  • If public end-points have been changed or added: does nginz need un upgrade?
  • If internal end-points have been added or changed: which services have to be deployed in a specific order?