Bootstrap agent APIs are split between a dropshot server and a raw TCP server

Bootstrap agent currently runs two servers:

1. A raw TCP server that uses length-prefixed JSON messages; this is how sled initialization requests arrive during RSS
2. A dropshot server that provides APIs to (a) get basic information about the sled (baseboard, list of components, status of RSS if it's running), (b) trigger RSS, (c) reset the rack, and (d) reset the sled.

The original intent behind 1 was that the bootstrap server, prior to rack setup, has no way to authenticate requests, so we would use sprockets to at least ensure that the requester running a valid Oxide root of trust. Wrapping sprockets around dropshot appeared difficult, so we opted for a raw server instead. However:

a. We don't actually have sprockets wired up yet
b. The bootstrap dropshot server has grown operations that are equally "dangerous" (2 b, c, d above)

making the split awkward and unnecessary. The easy option is to just leave this alone until we decide what we're doing about auth on the bootstrap network; we could also consider removing the raw TCP server and rolling sled init into the dropshot server.

Start by locating the bootstrap agent's raw TCP and Dropshot server entry points and tracing the sled initialization and management operations each exposes. Check whether sprockets or another authentication decision has been made. Done requires an agreed server architecture and implementation plan, or an explicit decision to defer the consolidation.