[Revert^2] Reject TetheringRequests that fuzzy-match existing ones

Legacy behavior will return success results to multiple startTethering
calls of the same type, even though the link layer can only support one
of those requests at a time (other than tethered AP + LOHS).

For B+, clean up this behavior by only allowing the amount of requests
that the link layer can concurrently support. To do this, we'll
introduce the concept of "fuzzy-matching" such that if a new request
fuzzy-matches an existing request (either pending or serving), this
indicates that the link layer cannot support the new request
concurrently, and we'll fail the new request with
TETHER_ERROR_DUPLICATE_REQUEST.

To keep track of serving requests, we'll store the request and it's
IpServer in RequestTracker when we call IpServer.enable(), and we'll
remove it (indexed by IpServer) when
1) Calling IpServer.onStop()
2) Calling IpServer.unwanted()
3) We detect an IpServer transition to AvailableState with error code

Note: This was originally merged as aosp/3529632 but was reverted due to
a crash when reading aconfig flags at boot. That issue has been fixed
here.

Reverted changes: /q/submissionid:3541662-revert-3527440-JRJJTQBUFC

Bug: 216524590
Test: atest TetheringTest RequestTrackerTest TetheringManagerTest

Change-Id: I87a1ed31927cda27d3b7fdd7c823b8f828f8d777
7 files changed