new push provider: nanopush

[jessepeterson]

The push library we've used forever, buford, was archived by the maintainers in early June of 2023. I quickly looked at a couple other libraries:

• https://github.com/sideshow/apns2 - a popular library. seem a bit large/kitchen-sink-ey, but not bad.
• https://github.com/edganiukov/apns - nice and tiny, but too app-focused (no custom payloads), not sure the correct non-JWT http2 forcing is done, either.

However, because our use of APNs for MDM purposes is limited in scope and we don't need the bells and whistles of an app-focused APNs library I took a stab at implementing just native HTTP/2 connections ourselves. There's not a whole lot of magic to make it work.

This PR plugs right into the PushProvider and PushProviderFactory interfaces and is enabled with a 1-line change in main().

It works as is:

$ curl -u nanomdm:$APIKEY "[::1]:9000/v1/push/AAABBB,CCCDDD"
{
	"status": {
		"AAABBB": {
			"push_result": "40B2A5DE-4B8A-4A6A-BC0E-BA4279F9F77F"
		},
		"CCCDDD": {
			"push_result": "6F089EFA-0FAD-D9AF-D742-5D48DA0E5BE9"
		}
	}
}

In addition to general tidy and docs I want to take a look at parallelization. The existing buford integration makes use of buford's Queue system when there is more than one notification. This spawns workers to try and speed up delivery. I'd like to think more on whether we should have a worker system, too, to quickly send notifications. I know that for our org, as DDM looms, we'll have much more multi-command/push situations coming up. Though, I want to think through how parallel the HTTP library itself is to see if this is necessary, because we issue all requests to a single http.Client{}.

[jessepeterson]

Added concurrent push sending which, according buford's issue implementing this feature (and the referenced issue) does appear to improve performance.

Also: added a test, made nanopush provider+factory default, and fixed error reporting by the parent push service, and are now passing the context to the provider.