Currently, NetworkRequest has several types of requests (LISTEN,
TRACK_DEFAULT, REQUEST, BACKGROUND_REQUEST), and we expect more
to be added.

There are really three categories of request:
1. Requests satisfied by only one network and will keep that
   network up, and thus need to be sent to NetworkProviders:
   REQUEST, BACKGROUND_REQUEST.
2. Requests satisfied by only one network but will not keep that
   network up: TRACK_DEFAULT
3. Requests satisfied by multiple networks and will not keep any
   networks up: LISTEN.

Unfortunately the separation is not very clear. Currently, for
any valid request, either isListen() will return true or
isRequest() will return true. This makes it impossible to tell
whether a particular request should be sent to NetworkProviders,
so the current code sends TRACK_DEFAULT requests to
NetworkProviders as well. This is incorrect - a TRACK_DEFAULT
should never keep a network up, for example.

This CL attempts to clarify things by making isRequest() return
false for TRACK_DEFAULT requests and thus never sending them to
NetworkProviders. After this CL:

- isRequest will return true only for requests that attempt to
  bring up or keep up a network.
- isListen will return true only for requests that match multiple
  networks but do not keep any of them up.
- Neither will return true for TRACK_DEFAULT.

Test: atest ConnectivityServiceTest
Change-Id: I7aad30ade8f7ab2a179e53483d9afd8675f64a12

Revert submission 1553146-android_util

Reason for revert: Build Breakage aosp-master/db845c-userdebug @ 7128996
Reverted Changes:
Ia39f6e03f:[Mainline] Migrate android.utils package items
Iaf99140d6:[Mainline] Migrate android.utils package items

Change-Id: I5bdaec5d1a87436510c3e05fadaf0124d86b1bdf

* changes:
  Stubbed setOemNetworkPreference in Connectivity
  Update OemNetworkPreferences to use 1:1 Map

Change-Id: Ia81dd386551db0a3c8bc73c03a6991b3c7c05770

* changes:
  Parse proto tombstones.
  Extract tombstone tracking to a separate service.

Test: CTS test.
Change-Id: I2a1edcf275da02cf005b6600450d152530eceaa9

* changes:
  Remove use of locks in VcnGatewayConnection.
  Support Safemode for VCNs.

Change-Id: I15afb8f80a3d067af522707748a5b07c015af138

...in order to be able to resolve IKE classes. Note that this can be
removed once the prebuilt stub in prebuilts/sdk contains IKE, which
can be achieved with a new import after this CL is submitted:
I10759d22eaba4861b7d7f283b551156f09f54675

Bug: 177266501
Test: m
Change-Id: I7229b1486e7170acca5da8f1b7874e5eaaecb1db

This facilities easier updating when new classes get added.

Bug: 177266501
Test: m
Change-Id: I85b3832681f0455093d2a33ace7dbc1028a1a5ff

Linger timer mechanism will be used for both "linger" and
"nascent" states. To prevent confusion, rename the linger
timer and related functions to more generic name.

Test: TH
Bug: 175180558
Change-Id: I652f7c65c2f8bc58fb9d3316480f23a9709eccce

* changes:
  Fix the legacy VPN tests that start racoon.
  Make testLegacyLockdownVpn more realistic.

This is a partial cherry-pick of change:
I5eedb571c9d78862115dfdc5dae1cf2a35343580

for connectivity classes.

Bug: 170883422
Test: m
Merged-In: I5eedb571c9d78862115dfdc5dae1cf2a35343580
Change-Id: I7dc661863b73f4198ddb4f3a1566583d0f07db3c

Update doc for onWrap/onUnwrap functions to further clarify how
exceptions should be thrown.

Bug: 172780686
Test: TH
Change-Id: I2bd8b80648074d0b6026487cb0b5791dca6cdc18

These tests do not actually work, or at least not as designed.
What happens when they are run is that creating/connecting the
VPN throws an exception. The call to legacyRunnerReady.block()
times out after 10 seconds because the condition variable is
never opened, but the doesn't notice the timeout becasue it
doesn't check the return value of block().

There are two reasons for the VPN not coming up.
1. VpnConfig.getIntentForStatusPanel calls into PendingIntent and
   ActivityManager statics, which bypass all the mocks and fail
   with an appops denial. Fix this by making it a dependency.
2. The tests are broken due to the UserManager API changes
   tracked in b/175883995. Fixing by adding a bit of ad-hoc code
   into startLegacyVpn, with a TODO to delete it once the rest of
   the UserManager setup code is fixed.

Fix these and check the return value of block(). This ensures
that if any other breakage is added the test will actually fail.
Also check that the throw route survives all the way to the
LinkProperties sent to the agent.

Bug: 173331190
Test: atest com.android.server.connectivity.VpnTest
Change-Id: Ieb7f33bce283ac5ee562a912df8edb9c930ed2b0

Bug: 173331190
Test: test-only change
Change-Id: I81b5686244f479d967c826e29eba4feb396a09cf