Include enrollment details in /id response

[RebeccaMahany]

Background

After launcher is first installed and starts up, it must enroll with K2. It generates "enrollment details" that identify the device -- for example, the device's OS and serial number. It includes these enrollment details in its enrollment request to K2's device server. K2 uses these details to create a device corresponding to this launcher installation.

In the future, we want enrollment to happen at a different point in time -- during device trust. (This will enable both secretless launcher installations and multiple enrollments.) In preparation for this work, we want to start including the enrollment details in launcher's localserver response to the /id endpoint.

The enrollment details should not change over time, so we should be able to generate them once on launcher startup, cache them, and then refer to the cached data when constructing the response to the /id endpoint.

Requirements

• Generate the enrollment details on launcher startup, and cache them.
• Update the enrollment details after autoupdate happens.
• Since the enrollment details are cached, we don't need to generate them anew during enrollment -- update enrollment to use the cached enrollment details. (Nothing else needs to change about enrollment at this time, though -- launcher should still perform enrollment as expected.)
• Include enrollment details in every response to the /id endpoint. The K2 side to consume this data hasn't been implemented yet, so there isn't a hard requirement for how this data should be structured. It is probably reasonable for it to exist at the top level of the response (same as RequestId and Status), and for the data format to remain the same as it currently is defined in service.EnrollmentDetails.

Relevant code links

• Generation of enrollment details: https://github.com/kolide/launcher/blob/main/pkg/osquery/enrollment_details.go
• /id endpoint: https://github.com/kolide/launcher/blob/main/ee/localserver/request-id.go

[directionless]

The enrollment details should not change over time, so we should be able to generate them once on launcher startup, cache them, and then refer to the cached data when constructing the response to the /id endpoint.

Probably need to regenerate it at autoupdate restarts, But yeah

[RebeccaMahany]

@directionless thank you, added to the requirements list!