Fix retry logic for TSHttpTxnServerAddrSet (issue #12611)

[bryancall]

When a plugin uses TSHttpTxnServerAddrSet() to set a server address and the connection fails, ATS should retry by calling the OS_DNS hook again to allow the plugin to provide an alternative address. However, the retry logic was missing handling for the USE_API case.

Changes:

• Added retry handling for ResolveInfo::OS_Addr::USE_API in handle_response_from_server()
• Clears dns_info.resolved_p to trigger OS_DNS hook re-execution
• Resets os_addr_style to TRY_DEFAULT to allow normal flow
• Clears server_request to allow it to be rebuilt for new destination
• Added api_server_addr_set_retried flag to prevent infinite retry loops
• Added test plugin and autest to verify the fix
• Updated TSHttpTxnServerAddrSet documentation to clarify retry behavior

Fixes #12611

[bryancall]

Why limit to 1 retry:

The retry logic intentionally allows only one additional OS_DNS hook call rather than using connect_attempts_max_retries. This avoids a combinatorial explosion of connection attempts:

• With 1 OS_DNS retry and connect_attempts_max_retries=3: up to 6 total connection attempts (2 addresses × 3 retries each)
• If we used connect_attempts_max_retries for OS_DNS retries too: up to 12 attempts (4 addresses × 3 retries each)

The single retry gives the plugin one opportunity to provide an alternative address on connection failure, which matches what issue #12611 requested. This keeps latency bounded while still enabling the documented retry behavior.

Since this is working and we have a test, adding an additional configuration option on how many times to retry the DNS would be easy to do.

[masaori335]

Adding ResolveInfo::OS_Addr::USE_API case seems make sense. Also, retrying only once is reasonable.