Move applying underlying caps from Vpn to ConnectivityService.

Add support to ConnectivityService to track underlying networks
directly instead of through the Vpn class.

1. Communicate all information necessary to propagate underlying
   network capabilities to ConnectivityService via NetworkAgent.
   This includes:
   a. Underlying networks:
      - Add SystemApi for NetworkAgent to declare its underlying
        networks to ConnectivityService, and use it in Vpn.
      - Add a new declaredUnderlyingNetworks member to
        NetworkAgentInfo and store the underlying networks in it.
	Move propagation of underlying network capabilities to
	mixInCapabilities, which is a natural place for it.
   b. "Always metered" bit:
      - Communicate this to ConnectivityService via the existing
        NOT_METERED capability. Store it in a new declaredMetered
	boolean in NetworkAgentInfo to separate it cleanly from
	the NOT_METERED bit in the capabilities, which depends on
	whether the underlying networks are metered or not. In
	order to ensure that this is only ever changed when a NC
	update is received from a NetworkAgent, define a new
	processCapabilitiesFromAgent similar to the existing
        processLinkPropertiesFromAgent.

2. Ensure that propagating underlying network capabilities does
   not read the VPN's NetworkCapabilities. In order to do this,
   ensure that all relevant information on underlying networks
   and metering is sent to ConnectivityService at NetworkAgent
   registration time. CS still calls Vpn#updateCapabilities when
   a user is added/removed, but that is deleted in a future CL.

3. Slightly generalize propagating underlying network
   capabilities because there may be other network types that
   also have underlying networks that aren't VPNs (e.g., VCN).
   - Introduce a new supportsUnderlyingNetworks() boolean method
     in NetworkAgentInfo.
   - Rename updateAllVpnsCapabilities to
     propagateUnderlyingNetworkCapabilities.

This commit does not move the actual logic of calculating the
underlying capabilities out of Vpn.java. That can be done in a
subsequent change once CS stops calling getUnderlyingNetworks().

This commit also does not modify any of the other code in CS that
directly accesses VPNs' underlying networks.

Bug: 173331190
Test: passes existing tests in ConnectivityServiceTest
Test: CTS test in r.android.com/1511114
Test: atest CtsNetTestCases:Ikev2VpnTest HostsideVpnTests
Change-Id: I5f76cb1aa4866efed3d5c4590e931fdb0e994f8d