Tracking issue for System Update API (phase 1)

[david-crespo]

RFD 322 System Update API outlines the external API but leaves the internals unspecified. #250 is a tracking issue with great detail on the internals. Initial API work is happening in #2100.

• Endpoints according to RFD 348
  • Get current system update status (version range + updating or steady) Operator View: Updates - what version am I on? #2038
  • Get tree of component statuses/versions
  • List available updates Operator View: Updates - what version is available? #2039
  • Get system update by version string
  • Get component updates for system update
  • Update dry run/impact summary Operator View: Updates - what's the impact of the update? #2040
  • Start update
  • Stop update
  • List update deployment history (update runs)
• DB tables
  • System updates
  • Component updates + assoc with system updates
  • Updateable component versions + status
  • Update deployments w/ status/outcome
  • Store semver versions in DB as a string with proper ser/de into semver::Version
  • Enforce uniqueness of semver version
• Connection to underlying systems
  • TUF repo scan populates system_update and component_update tables (original PR: [v2] TUF integration in Nexus + update artifact fetching by sled-agent #717)

[david-crespo]

Marking this completed as a kind of phase 1. Will make a new tracking issue for the remaining work.