storage: move storage_state module to protocol::server::worker

[benesch]

I think this module movement was just missed in #13626. It seems to logically belong in the server module introduced in #13626.

Motivation

• This PR refactors existing code.

Checklist

• [x] This PR has adequate test coverage / QA involvement has been duly considered.

• [ ] This PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way) and therefore is tagged with a T-protobuf label.

• [x] This PR includes the following user-facing behavior changes:

  • n/a

[aljoscha]

I think this was left as is on purpose. The storage_state is an implementation detail of storaged, and not something in the protocol between client and server. cc @petrosagg

[benesch]

I think this was left as is on purpose. The storage_state is an implementation detail of storaged, and not something in the protocol between client and server. cc @petrosagg

Yeah, for sure, it's the implementation of the server—but the same is true of a bunch of the existing code in protocol::client and protocol::server. There's plenty of implementation details in those modules already. It's the pub vs. not distinction that tucks away the public vs. private stuff.

IMO an optimal module arrangement would look something like this:

• controller — storage controller implementation
• collection — public submodule for reading a storage collection from outside of storage
• host — storage host implementation (what's currently called "protocol")
  • client — public submodule for storage host client
  • server — public submodule for storage host server
    • decode — private submodule for decoding operators
    • render — private submodule for ... other? ... operators
    • source — private submodule for source operators
    • sink — private submodule for sink operators
• types — the types used in the public controller API