res_rtp_asterisk: Add option to control stun host resolution when TTL = 0

[gtjoseph]

If a hostname is specified for stunaddr in rtp.conf, periodic DNS resolution
is enabled based on the TTL returned in the DNS results. If the TTL returned
is 0, it means that the next time the IP address is needed, it must be
looked up again. I.E. Don't cache. Historically (and incorrectly) however,
res_rtp_asterisk stopped the periodic resolution and never re-resolved the
hostname again

UserNote: A new stunaddr_reresolve_ttl_0 parameter has been added to rtp.conf
that allows control over what happens when a STUN server hostname lookup
returns a TTL of 0. The values can be set as follows:

• 'never': This is the historical (and current default) behavior of not doing
  any further lookups and continuing to use the last successful result until
  Asterisk is restarted or rtp.conf is reloaded.
• 'always': Re-resolve the hostname every time and if the result is a TTL
  greater than zero, restart periodic resolution. CAUTION: DNS lookups are
  synchronous so call setup will block until a respoonse is received.
• 'trigger_only': Use the last successful result for the current call and
  restart periodic resolution. This allows the current call to continue
  immediately but will re-resolve in the background for the benefit of
  future calls. If the result is still a TTL of 0, periodic resolution
  will stop again and the next call will trigger again.

Resolves: #1858

[gtjoseph]

cherry-pick-to: 20
cherry-pick-to: 22
cherry-pick-to: 23

[github-actions]

Workflow Check failed
master-app_dial: FAILED TEST: apps/queues/transfer/caller_attended
master-ari1: FAILED TEST: rest_api/external_interaction/attended_transfer/stasis_bridge_to_non_stasis_app

[seanbright]

Can we make the default in master be the RFC compliant behavior?

[gtjoseph]

Can we make the default in master be the RFC compliant behavior?

Hmmm. It's a small enough tweak that it shouldn't cause cherry-pick issues later. Let me chat with @jcolp in the morning.

EDIT: I think it'd have to be "trigger_only" otherwise unexpected delays in call setup could occur.

[jcolp]

I think changing the default in master to something more reasonable is fine.

[gtjoseph]

I'm moving this back to draft. I need to think a bit more about the "trigger_only" option. If the TTL is always 0 and we keep triggering with a large call volume there's going to be a lot of churn going on and I'm not quite sure I like how locking is happening. Maybe I need to check if a resolution is already in-flight before scheduling another one.