Make package networking more flexible/injectable

Nobody has claimed this yet.

Hi, this may be a slightly unusual request, so I want to explain the use case.

I am building a lab/networking tool called Kraken: https://github.com/yisrael-haber/kraken

The project uses gVisor user-space netstacks and Starlark scripting to let users create independent network identities and then interact with the network through those identities. The goal is to give users a UI where they can adopt/build identities, inspect and modify lower-level packet flow, and run higher-level scripts and services through the same underlying network engine.

In practice, this means I try hard to make all client/server networking go through the tool’s own network stacks instead of directly through the host OS. For example, Kraken has embedded echo/HTTP/HTTPS/SSH services and identity-backed scripting sockets, so traffic can be tied clearly to a specific modeled identity.

I have been looking at using this project as a protocol library inside that scripting/runtime layer. A lot of the code is very useful for this: packet parsing/generation, DCE/RPC, NTLM, SMB-related code, and the Windows protocol packages in general.

The main difficulty is that some subpackages appear to create their own network connections internally, or otherwise assume OS-backed dialing. That is a reasonable default for normal tool usage, but it makes it hard to use those packages in projects where the network transport needs to be supplied by the caller.

What would help a lot is having more package APIs accept one of these shapes where possible:

- an existing `net.Conn`
- a small dialer interface
- a `context.Context` aware dial function
- an already-created protocol client/session, such as an existing DCE/RPC client

I am not asking for the command-line tools to change behavior. The default path can still use normal OS networking. The request is mainly for the reusable packages to make the transport injectable where it is practical, so projects like mine can route traffic through custom stacks.

I would be happy to help contribute this if it fits the direction of the project. I do not want to push a design that conflicts with your goals, though, so I wanted to open an issue first and ask whether this kind of change would be welcome.

The goal is not to make every package abstract. It is just to make the network boundary injectable in places where the protocol logic is otherwise reusable.
Thanks for the work on this project. It is already useful for the kind of protocol scripting and lab tooling I am trying to build.

Start by identifying the reusable subpackages that create network connections internally and review their current package APIs, along with the CLI entry points that should retain default OS networking. Define the smallest practical transport-injection boundary and confirm that completion preserves existing CLI behavior while allowing callers to supply connections, dialers, contexts, or protocol sessions.

Written by the indexing model from the issue text.