Related to https://github.com/fleetdm/fleet/issues/9653 I couldn't find
any documentation to back this up, but I have a strong suspicion that
the `os` field in the device sync response might come empty in some
scenarios (particularly, when a laptop is brand new, which is hard to
reproduce 😅)
My thoughts are:
1. For the recently purchased MacBooks,
`IngestMDMAppleDevicesFromDEPSync` didn't create an entry in the
database, BUT `nanodep.Assigner.ProcessDeviceResponse` correctly
assigned a DEP profile (the devices were able to enroll). Both methods
filter by `op_type` but only ours filters by `os`.
2. I think this is safe-ish to do, as you will normally assign a MDM
server per device type in ABM
3. I have added extra logs to try to prove this hypothesis next time a
brand new device comes in, let's keep an eye on and re-evaluate this
approach.
**Use nano's multi service**
This allows us to integrate more seamlessly with nano and to run our
custom MDM logic _after_ the request was handled by nano, which gives us
more flexibility (for example: now we can issue commands after a
TokenUpdate message)
From nano's code:
> MultiService executes multiple services for the same service calls.
> The first service returns values or errors to the caller. We give the
> first service a chance to alter any 'core' request data (say, the
> Enrollment ID) by waiting for it to finish then we run the remaining
> services' calls in parallel.
**Integration tests + fixes**
- Move some of the service logic from `cmd/` to `server/service`
- Add integration tests for the MDM enrollment flow, including SCEP
authentication.
- Fixed a bug that set `host_mdm.mdm_id = 0` during MDM enrollment due
to how MySQL reports the last insert id when `ON DUPLICATE KEY` is
used.
- Completely remove the host row from `host_mdm` when a device is
unenrolled from MDM to match the behavior of how we ingest MDM data
from osquery
Related to https://github.com/fleetdm/fleet/issues/8708,
https://github.com/fleetdm/fleet/issues/9034
