RSS should use Reconfigurator to develop its service plan

As of #5244, RSS generates a blueprint describing the service plan it produced and hands that off to Nexus, seeding the Reconfigurator with an accurate plan that doesn't require a support operator to generate one from an inventory collection. However, RSS's implementation of this is a little weird: we keep all the existing service-plan-creation logic, and then after it runs, we derive a blueprint from the plan. Once the Reconfigurator supports all control plane services, we could instead use it to generate the RSS plan.

Once Reconfigurator is automated, we could also consider having RSS set up a significantly reduced set of services (basically: the minimum set required to get Nexus+Reconfigurator up and running), and allowing Reconfigurator to flesh out the remaining services after rack initialization.

This is strongly related to #732, although many of the implementation details have been fleshed out since that issue was created, so possibly supersedes it.

Read the RSS service-plan creation flow alongside the Reconfigurator work described in #5244, and compare the earlier direction in #732. Determine the service coverage needed before RSS can delegate plan generation. Done means RSS uses Reconfigurator for its service plan without retaining the current duplicate plan-generation path.