"sled add" could be more asynchronous

Right now, the "add sled" external API call invokes a PUT /sleds API on some sled agent and waits for it to complete. That process in turn communicates with bootstrap agent on the new sled to start Sled Agent on the new sled. Aside from #5121, we expect this to be fairly quick. But things like #5121 do happen. We did #5116 as a band-aid, but it's not a great solution because it means an API call could block for several minutes. That's not a great pattern for HTTP for lots of reasons.

What if instead we moved this to Reconfigurator (blueprint planning/execution)? Proposal:

• the "add sled" API immediately inserts a sled record with state uninitialized
• during planning, if we see any sleds in state "uninitialized", we put them into a set of sleds_to_initialize: BTreeSet<Uuid> (or equivalent)
• during blueprint execution, for each sled in that state, we invoke the PUT /sleds API on some sled agent

This assumes that the PUT /sleds request is idempotent and can be invoked concurrently against multiple sled agents for the same new sled.

Start with the “add sled” API and the Reconfigurator planning and blueprint execution paths named in the proposal. Trace how the sled record and its state are handled, then verify that the API returns without waiting and that uninitialized sleds are collected and initialized during planning and execution.