Implement separate "device policies" API for checking Desktop notifications

[zwass]

As discussed in #5579 (comment), this should be completed before bringing Desktop out of beta.

Currently defined /device endpoints:

fleet/server/service/handler.go

Lines 391 to 396 in d84d600

	// device-authenticated endpoints
	de := newDeviceAuthenticatedEndpointer(svc, logger, opts, r, apiVersions...)
	de.GET("/api/_version_/fleet/device/{token}", getDeviceHostEndpoint, getDeviceHostRequest{})
	de.POST("/api/_version_/fleet/device/{token}/refetch", refetchDeviceHostEndpoint, refetchDeviceHostRequest{})
	de.GET("/api/_version_/fleet/device/{token}/device_mapping", listDeviceHostDeviceMappingEndpoint, listDeviceHostDeviceMappingRequest{})
	de.GET("/api/_version_/fleet/device/{token}/macadmins", getDeviceMacadminsDataEndpoint, getDeviceMacadminsDataRequest{})

We need to add one to fetch the host's policies (+ their results, similar to how they are returned in the /api/_version_/fleet/device/{token} endpoint).

NOTE(lucas): We should expose this endpoint to be used by Go code (the Fleet Desktop tray application is made in Go: orbit/cmd/desktop/desktop.go). Should be similar to what we have for fleetctl in the server/service/client_*.go files.
Why? @sharvilshah had to copy the types to be able to make requests and parse the responses: e.g.

fleet/orbit/cmd/desktop/desktop.go

Lines 22 to 49 in 8e5cedf

	type Response struct {
	Host struct {
	Policies []struct {
	ID int `json:"id"`
	Name string `json:"name"`
	Query string `json:"query"`
	Description string `json:"description"`
	AuthorID int `json:"author_id"`
	AuthorName string `json:"author_name"`
	AuthorEmail string `json:"author_email"`
	TeamID interface{} `json:"team_id"`
	Resolution string `json:"resolution"`
	Platform string `json:"platform"`
	CreatedAt time.Time `json:"created_at"`
	UpdatedAt time.Time `json:"updated_at"`
	Response string `json:"response"`
	} `json:"policies"`
	Status string `json:"status"`
	DisplayText string `json:"display_text"`
	} `json:"host"`
	License struct {
	Tier string `json:"tier"`
	Organization string `json:"organization"`
	DeviceCount int `json:"device_count"`
	Expiration time.Time `json:"expiration"`
	Note string `json:"note"`
	} `json:"license"`
	}

[zwass]

@chiiph can you please take this over for planning as discussed in #5579? Feel free to edit the top comment description.

I've moved it into the "Prioritized" column to indicate we should try to get it ready for scheduling in the upcoming release (4.16.0).

[roperzh]

NOTE(lucas): We should expose this endpoint to be used by Go code (the Fleet Desktop tray application is made in Go: orbit/cmd/desktop/desktop.go). Should be similar to what we have for fleetctl in the server/service/client_*.go files.

@lucasmrod would you mind thinking through this with me to make sure we're on the same page? First thing that comes to mind is to add a new public method to server/service/client_*.go, initialize a new client in fleet desktop and use it.

Is this what you had in mind? What makes me think is that there must be a reason why we copied the type declaration instead of just using Client.HostByIdentifier in the current implementation. Was just to speed up the feature without having to deal with setting up a new Client instance?

edit: I was just confused about ^, but I would still be helpful to hear you thoughts about adding a new server/service/client_*.go file vs putting the code somewhere else

[roperzh]

we discussed in a call with @lucasmrod , we're going to:

• If possible, reuse the same client we have in server/service/client.go
• If the client assumes a bearer token (these endpoints are authenticated via the device token), create a new client
• Import github.com/fleetdm/fleet/server/service into orbit, keep an eye on increased build size, but we suspect this shouldn't be a problem

[lucasmrod]

If possible, reuse the same client we have in server/service/client.go

Introducing a separate DeviceClient type in such package makes more sense (as the authentication AND API are different).

Import github.com/fleetdm/fleet/server/service into orbit, keep an eye on increased build size, but we suspect this shouldn't be a problem

+1, can be tackled at a later iteration.