Rely on lost context callbacks intead of polling

The compositor is notified of a lost context event through the ContextProvider's
lost context callback. We also had various pieces of code that expilcitly polled
the context to see if it was still alive and attempted to fail faster if the context
was lost. This logic is not really necessary, however, since on a lost context the
callback will always be invoked sooner or later and these early exit + recover paths
add significantly complexity to the compositor and the context bindings.

This strips out code that polls for a lost context inside cc and instead performs
recovery on the lost context callback.

This also stops attempting to make the compositor's context current before making calls.
Since we use the object-oriented C++ bindings to talk to the context implementation,
there's no need to update the current context pointer in TLS in order to issue GL calls.
Ganesh still uses the TLS pointer for its bindings so we do have an entry point to make
that context current when necessary.

BUG=181120

Review URL: https://codereview.chromium.org/107193003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239415 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 239415
Disable the network connectivity tests. jar and I have found cases if
there is a pending read or pending write, we could read/write into a
buffer that was already released.

BUG=273917, 326715
R=jar@chromium.org

Review URL: https://codereview.chromium.org/107413005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239416 0039d316-1c4b-4281-b951-d872f2087c98
Fixed CDD.
"custom_display_name" must be set only if the "name" field is CUSTOM.
Removed optional values.

Review URL: https://codereview.chromium.org/108253004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239417 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 239417