add builder interface for making servers

[davepacheco]

Split from #1120. Depends on #1121.

This PR adds a new builder interface for constructing servers. I changed a few of the examples and tests to use it, but not all of them yet in case we want to iterate on the interface in review.

[ahl]

looks good.

What's your thinking on if/when we replace the old interface?

[davepacheco]

As usual for non-trivial interfaces changes, even though this is not a breaking one, I like to try it on Omicron first. That worked out pretty well:
oxidecomputer/omicron#6730

All of these were pretty trivial to convert and all of them immediately called start() on the new HttpServerStarter.

[davepacheco]

Windows CI is failing:
https://github.com/oxidecomputer/dropshot/actions/runs/11115639926/job/30884457056#step:7:898

This appears to be steffengy/schannel-rs#106. We're getting schannel via:

dap@zathras dropshot-builder-only $ cargo tree -i schannel --target all
schannel v0.1.19
├── native-tls v0.2.12
│   ├── hyper-tls v0.6.0
│   │   └── reqwest v0.12.8
│   │       [dev-dependencies]
│   │       └── dropshot v0.12.1-dev (/Users/dap/oxide/dropshot-builder-only/dropshot)
│   ├── reqwest v0.12.8 (*)
│   └── tokio-native-tls v0.3.1
│       ├── hyper-tls v0.6.0 (*)
│       └── reqwest v0.12.8 (*)
└── rustls-native-certs v0.7.0
    └── hyper-rustls v0.26.0
        [dev-dependencies]
        └── dropshot v0.12.1-dev (/Users/dap/oxide/dropshot-builder-only/dropshot)

One of those is hyper-rustls, which we're a little behind on (see #1110) and it's possible updating that may help? For now though I'm going to disable this test on Windows because this isn't trying to verify TLS functionality (we do that elsewhere) -- just that this constructor does successfully start TLS.

[davepacheco]

Despite my threat to just disable this test on Windows, the lingering fear of papering over something important keeps me from doing it.

I was able to work around the panic by updating schannel with cargo update to 0.1.24. Now on Windows we get a failure to verify the TLS certificate, even though we're adding it to the reqwest root store. Here are some related potentially issues:

seanmonstar/reqwest#826
sfackler/rust-native-tls#233

It seems possible that the certificate being generated by rcgen, which is P-256, is not supported with the native Windows APIs that are being used here.

I'm going to try using rustls-tls (this is just for our own tests) to see if that helps.