chore(daemon): remove untrusted socket

[thp-canonical]

As part of working on #358, we found out that the untrusted socket is not used, and so can be removed (in preparation for porting the AccessChecker changes from snapd in #358).

Indicators that it's not used:

If we look at how canAccess works, if we match on untrustedSocketPath (isUntrusted), the only way for canAccess to allow the request is when c.UntrustedOK is true (otherwise it unconditionally returns accessUnauthorized immediately):

if isUntrusted {
	if c.UntrustedOK {
		return accessOK
	}
	return accessUnauthorized
}

So in order for any API calls to be allowed with the untrusted socket (assuming all API calls go through canAccess), we would need to have a Command defined with UntrustedOK: true. Checking the Pebble codebase, no such Command definition exists, which means that even if any application would use the untrusted socket currently, all API calls would return accessUnauthorized unconditionally for this socket.

The untrusted socket as well as UntrustedOK in Command were already part of the initial import commit (50466ba), so seem to be an inheritance from snapd that haven't seen use in Pebble since then. The corresponding snapd sources from around November 10th, 2020 seem to call these SnapOK (UntrustedOK), dirs.SnapSocket (untrustedSocketPath) and snapListener (untrustedListener).

Due to gofmt and removal of struct members with the longest names, this PR is best reviewed with the "hide whitespace" option.

[hpidcock]

I am happy with the justification for this removal. If at a point in the future we need such a socket, we can reintroduce it. Thoughts @benhoyt ?

[benhoyt]

Sorry, I've run out of time today -- will need to take a closer look early next week. (Sounds reasonable though.)

[benhoyt]

Yep, I agree this removal/simplification makes sense -- in preparation for porting the AccessChecker changes from snapd in #358.

[benhoyt]

Oops, accidental close.