In diagnosing issue #488043 and a duplicate of it, I noticed the socket pools don't log very well. This bug tracks a bunch of stuff to improve this:

1. SSL requests make two CONNECT_JOBs. It's hard to tell which is the SSLConnectJob and which is the TransportConnectJob. Per discussion with mmenke@, split these into different source types per subclass.

2. Socket pools mint their ConnectJob parameters from a particular request and assume these parameters are the same across the group. It's pretty easy to mess this up (issue #488043). Add a link from the ConnectJob up to the request which spawned it. Note this is distinct from the request it was bound to. Add this to SOCKET_POOL_CONNECT_JOB.

3. On success, we get the following links:

  CONNECT_JOB => SOCKET to find out which socket you used (absent on idle)
  request => CONNECT_JOB to find out which ConnectJob you bound to (absent on idle)
  request => SOCKET to find out which socket you ultimately got
  SOCKET => request to find out who is using a socket

On error, we're missing a lot of these. Note that certificate errors and other errors behave differently. (It depends on whether SetSocket gets called anyway.) It would be useful to be able to answer questions like:

- This object at this layer failed with ERR_FOO. Where did ERR_FOO come from?
- This object at this layer produced (or inherited) ERR_FOO. Where did ERR_FOO get fed into?

I feel a little weird adding the full mix of edges since there's some redundancy here, but we'll see. I'll stare at that once I've done 1 and 2.