The candicates of `proto_add_host_dependency` should be OR'd instead of AND'd

Most VPN protocols implemented by OpenWRT use proto_add_host_dependency to enforce the presence of a route to the endpoint as shown in https://github.com/search?q=org%3Aopenwrt+proto_add_host_dependency+language%3AShell&type=code. In addition, resolveip is employed to resolve the endpoint's address if set as a domain. When the endpoint domain resolves to multiple IPs, many protocol implementations iterate over and use proto_add_host_dependency to add all IPs returned by resolveip. Examples are PPTP: https://github.com/openwrt/openwrt/blob/1a47ce5ff2f2db07fca8fc28801c0a78cbf19fe4/package/network/services/ppp/files/ppp.sh#L298-L301 and L2TP: https://github.com/openwrt/packages/blob/8bbc9c7d796fc4685c9839839bed3b057aa18397/net/xl2tpd/files/l2tp.sh#L33-L36

In the multi-IP case, the interface should be brought up when any one of the IPs is reachable, from what I understand. In other words, the IP list added by proto_add_host_dependency should be OR'd. However, its internal implementation appears to require all IPs in the list to be reachable simultaneously, i.e., the IPs are AND'd, which doesn't make much sense to me.

In my scenario, the VPN server is in a dual-stack network so its domain has both A and AAAA records. The VPN client (running OpenWRT) is v4-only and has the following setup:

config interface 'vpn'
	option proto 'l2tp'
	option username 'username'
	option password 'password'
	option ipv6 'auto'
	option server 'vpn.example.com'  # has both A and AAAA records

Both the A and AAAA records of example.com are added by proto_add_host_dependency in proto_l2tp_setup. Since the client is v4-only, there won't be a route to the v6 address so the L2TP interface is never brought up. The workaround I'm taking is to create a 4.vpn.example.com that has an A record only.

I believe this is a general issue and the internal behavior of proto_add_host_dependency should be fixed rather than adding hacks to protocol implementations.

Cc: @yousong

Start at the internal implementation of proto_add_host_dependency in netifd, then compare its behavior with the PPTP and L2TP examples linked in the issue. Reproduce the dual-stack, v4-only scenario and determine whether multiple dependencies are evaluated as AND or OR. Done means an interface can start when any reachable endpoint address satisfies the dependency, with the reported scenario covered by an appropriate test.