Separate instance_client and more precise error types

[ggevay]

This is a refactoring related to the frontend peek sequencing, addressing the second paragraph of #33713 (comment) + other related discussions with Moritz and Jan.

It's split into commits meaningfully. (I could also split it up to into multiple PRs if desired.)

The first commit is just code movement, moving out the Client from instance.rs into a new file instance_client.rs, and renaming it to InstanceClient. (This is used by the frontend peek sequencing directly, bypassing the ComputeController, because we don't want the Coordinator to be a bottleneck for fast-path peeks.)

The second commit makes many function return types specify more precise error types. This made CollectionLookupError used only by PeekClient, so I moved it there.

The third commit just resolves some of the /// TODO(database-issues#7533): Add documentation. comments in controller/error.rs.

[antiguru]

Do you mind splitting the PR in three? It's distinct changes and would be easier to review if they're separate.

The client change seems to be purely code movement, I'm not sure it's actually worth doing.

[ggevay]

@antiguru, moving stuff into a new instance_client.rs was @teskje's idea, see here. I'm fine either way.

[teskje]

Yeah, the intention is twofold:

• Having a separate module for the public instance client allows us to keep the instance module private, which makes it easier to ensure that we don't expose more of its contents over time.
• Some of the errors returned by InstanceClient are similar, but different to errors returned by the Instance task (in instance.rs) or errors returned by the ComputeController client (in error.rs). Having a separate module gives us a place to define the InstanceClient errors without running into name conflicts.

[ggevay]

Ok, separated into 3 PRs: #35010, #35011, #35012