Fix a bug where modern network agents start in UNKNOWN

Modern network agents are supposed to have the following
lifecycle :
• Construct the agent
• Declare itself to connectivity by calling #register()
• Possibly do some setup
• Declare connected by calling #markConnected()
• Declare disconnected by calling #unregister()

Internally ConnectivityService still manages the state
with deprecated NetworkInfo, which has a lot of possible
detailed states, most of which are now unused. Internally,
the steps above translate to the states below :
• When the agent calls #register() it starts in state
  CONNECTING
• When it calls #markConnected() it goes to CONNECTED
• When it calls #unregister() it goes to DISCONNECTED which
  triggers the flow that disconnects it immediately
• ConnectivityService also synthesizes the SUSPENDED state
  under some situations, but that's not relevant here.

The translation above is done by the NetworkAgent class,
which translates #register(), #markConnected() and
The only valid lifecyle for new agents is thus :

CONNECTING → CONNECTED → disconnect
                 ↕         ↑
             SUSPENDED ───┘

Note that in the above scheme, there is no space for the
UNKNOWN state, which is only used by legacy network agents.
However, the constructor for NetworkInfo still starts with
UNKNOWN. Ideally the constructor for NetworkInfo would set
the info to CONNECTING instead, but this would be a very
visible change in behavior affecting many apps (especially
their tests), so for backward compatibility we can't do
that.

New network agents however don't expose their NetworkInfo
to the client code, so they can just be made to start in
CONNECTING the way it was meant.

Note that this didn't really have a concrete impact beyond
printing some logs as by and large the ConnectivityService
code handles UNKNOWN and CONNECTING the same way, or more
exactly it handles transitions to CONNECTED from UNKNOWN
and CONNECTING in the same way. The exception to this is
VPNs, which are not using the new agent API yet, and the
upcoming conversion is why this fix is actually needed now.

Bug: 170904131
Test: FrameworksNetTests NetworkStackTests
Test: new test in aosp/1460705
Change-Id: Ib7d906a7b29a0b9f000b90bc78558a7402852fa3