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>