Tidy up and comment daemon CLI

[Ericson2314]

Motivation

This is somewhat overkill as none of these functions are public a header, but I just like making all the code really nice and pretty :).

I hope the next person to touch this code will benefit.

Context

Some of the factoring out was taken from #7912 by @mupdt. Thanks!

Checklist for maintainers

Maintainers: tick if completed or explain if not relevant

• agreed on idea
• agreed on implementation strategy
• tests, as appropriate
  • functional tests - tests/**.sh
  • unit tests - src/*/tests
  • integration tests - tests/nixos/*
• documentation in the manual
• documentation in the internal API docs
• code and comments are self-explanatory
• commit message explains why the change was made
• new feature or incompatible change: updated release notes

Priorities

Add 👍 to pull requests you find important.

[roberth]

Just something I noticed about processStdioConnection now that it's a bit more independent.
Not an urgent issue because it's static (for now!) and clients knowing their trustedness is a new thing, but would prefer not to have latent problems either.

[roberth]

Instead of documenting a limitation, I think we could make it work.

Suggested change

	processConnection(store, from, to, Trusted, NotRecursive);
	processConnection(store, from, to, store->isTrustedClient(), NotRecursive);

The point of this mode of operation is that we forward everything, so that should probably include informing the client about their trustedness correctly.

[Ericson2314]

I actually went with the first one for 3 reasons:

1. I hope this can be a pure refactor and not change any behavior.
2. I don't think that change is enough to warrant removing the note: in the case where the underlying store is a LocalStore, for example, it will blindly return Trusted. So standard streams + non-RemoteStore still means an invalidated client.
3. It is good to kindly ferry along the whether the "next" store trusts the client, but we could do that in both the stdio and non-stdio cases.

So bottom line is I think this is a good idea, but it deserves is own follow-up PR.

[Ericson2314]

Also I remembered that the way it works today is that the trusting of operations in processConnection is based solely on this parameter, but the trusting status returned to the client already takes store->isTrustedClient() into account.

That means in a chained daemon situation that even if an intermediate daemon trusts the the client (and doesn't block any request) the result of store->isTrustedClient() is still the intersection of the trust of each link in the chain.

I actually think that might be good semantics:

1. Don't block requests on behalf of another store further down the chain, let the first untrusting store do the blocking.
2. Do accurately report to the eventual client whether privileged requests will actually go all the way through.