fix: make Client.Pull properly handle API errors (#452)
Currently the `Client.Pull` method is immediately checking the content
type for multipart, but we should also check for a regular API error.
This PR fixes that.
fix: avoid need to lock state for restart.Pending() (#451)
This change avoids the need to lock/unlock state when fetching
`restart.Pending()`, avoiding the need for one state lock/unlock on
every HTTP request. (We hope to get rid of the other lock/unlock by
removing warnings, but that's a separate issue.)
fix(snap): set Pebble version before snap builds (#450)
# Problem
When doing a `snapcraft remote-build`, Snapcraft will create a copy of
the project in Launchpad before running the snap build.
The **problem** is that Snapcraft seems to ignore tags while creating
the copy of the project, which means the `go generate ./cmd` in the
`snapcraft.yaml`'s `override-build` will never dynamically generate the
right version.
# Solution
This PR enforces the execution of `go generate ./cmd` as a pre-requisite
for running the snap build. I.e., for both local and remote builds, `go
generate ./cmd` must be run first, such that the `VERSION` and
`version_generated.go` files are staged in the repo, prior to the snap
build, such that the `override-build` script can simply rely on that
information and thus ignore the missing Git refs in the LP's project.
chore: use Go 1.22 (supported), in go.mod and binary builds (#449)
Per discussion with Harry, we'd like to bump up the minimum Go version
to a supported version (1.21 and 1.22). Might as well go up to 1.22
(that's what Juju is on now as well).
The PR updates the daemon to actually use UserState (which now has
access-level and UID feilds). The daemon now fetches the request's named
identity if one exists, otherwise it populates UserState with default
user based on the ucred UID. So UserState is always set -- this makes
the access checkers simpler and the notices API code simpler.
If there is a named identity (a non-nil `UserState`), that identity is
used, even if the "default UID-based auth" would let them in. So named
identities trump the default ("uid==0 || uid==daemon_uid" means admin;
any uid means read). For example, if you have a user `bob: {access:
untrusted, local: {user-id: 42}}` and are making a request with UID 42,
it'll only work for untrusted/open endpoints (`/v1/health` and
`/v1/system-info`), not the usual of any read API.
