net: rename BoundNetLog to NetLogWithSource

net/docs/crash-course-in-net-internals.md

 # A Crash Course in Debugging with about:net-internals
 
 This document is intended to help get people started debugging network errors
 with about:net-internals, with some commonly useful tips and tricks.  This
 document is aimed more at how to get started using some of its features to
 investigate bug reports, rather than as a feature overview.
 
 It would probably be useful to read
 [life-of-a-url-request.md](life-of-a-url-request.md) before this document.
 
@@ skipping 16 matching lines @@
 The other views are all snapshots of the current state of the main
 URLRequestContext's components, and are updated on a 5 second timer.  These will
 show objects that were created before about:net-internals was opened.  Most
 debugging is done with the Events view (which will be all this document
 covers), but it's good to be aware of this distinction.
 
 # Events vs Sources
 
 The Event View shows events logged by the NetLog.  The NetLog model is that
 long-lived network stack objects, called sources, emit events over their
-lifetime.  When looking at the code, a "BoundNetLog" object contains a source
+lifetime.  When looking at the code, a "NetLogWithSource" object contains a source
 ID, and a pointer to the NetLog the source emits events to.  Some events have a
 beginning and end point (during which other subevents may occur), and some only
 occur at a single point in time.  Generally only one event can be occuring for a
 source at a time.  If there can be multiple events doing completely independent
 thing, the code often uses new sources to represent the parallelism.
 
 "Sources" correspond to certain net objects, however, multiple layers of net/
 will often log to a single source.  Here are the main source types and what they
 include (Excluding HTTP2 [SPDY]/QUIC):
 
@@ skipping 126 matching lines @@
 things like HSTS redirects (URLRequestRedirectJob), AppCache, ServiceWorker,
 etc.  These generally don't log as much information, so it can be tricky to
 figure out what's going on with these.
 
 * Non-HTTP requests also appear in the log, and also generally don't log much
 (blob URLs, chrome URLs, etc).
 
 * Preconnects create a "HTTP_STREAM_JOB" event that may create multiple
 CONNECT_JOBs (or none) and is then destroyed.  These can be identified by the
 "SOCKET_POOL_CONNECTING_N_SOCKETS" events.