"sled add" could be more asynchronous

[davepacheco]

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.

[davepacheco]

This might be blocked on #4494?