s4:librpc/rpc: avoid using dcerpc_socket_peer_addr()

s4:librpc/rpc: avoid using dcerpc_socket_peer_addr()

We use information stored in the dcerpc_binding in order
to open a secondary connection.

The goals are:
- dcerpc_secondary_connection_* should just use the dcerpc_binding
  information for the first connection and just call dcerpc_pipe_connect_*
- Get rid of dcerpc_pipe->transport.* and just use a tstream_context.
  All other details should be maintained only by the higher levels.
- Hide dcerpc_pipe and dcecli_connection behind dcerpc_binding_handle.
- Have just one entry point to create a new connection. For source4/librpc
  this will be dcerpc_pipe_connect_*. For source3/rpc_client we need
  a similar function.
- We'll have a new dcerpc_connection layer, with also just one
  entry point to create a new connection.
- Replace dcerpc_pipe and dcecli_connection with the new dcerpc_connection layer.
- Replace rpc_pipe_client with the new dcerpc_connection layer.
- When the client side is unified we can change the server
  as it needs to act as a client in order to register the endpoint mappings.
- Then the core of the server will be changed to use the new dcerpc_connection
  layer.

As dcerpc_socket_peer_addr() uses p->transport.private_data
as 'struct sock_private', we should avoid it.
We can then remove dcerpc_unix_socket_path() and 'struct sock_private'.

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>