Merge `valence` and `valence_protocol`

[rj00a]

Describe the problem related to your feature request.

The current valence_protocol architecture has felt somewhat flawed and messy. I have identified a few reasons for this. It is for these reasons that I believe a general-purpose protocol crate that covers everyone's use case is not really feasible.

• Packets are often inherently context sensitive. Their full definition can rely on things well outside the scope of valence_protocol. A few examples:
  • The entity tracker update packet is just a meaningless blob of bytes in valence_protocol. The actual structure and data types used in the packet are defined in valence.
  • The update recipes packet depends on things defined in a registry to parse correctly. All solutions seem bad from the perspective of a general-purpose library.
  • The chunk data packet is a blob of bytes.
• There is tension between making the packets precise and making them generally applicable. e.g. should text component fields use the Text type, or should they just be strings?
• It's not clear when something should be a part of valence or valence_protocol.
• Some types are duplicated between the crates. The GameMode enum is defined in valence because we want it to be a Component. But valence_protocol needs it and it shouldn't depend on bevy_ecs. So it's defined in both.
• glam is not used in the packets because maybe some hypothetical user of valence_protocol doesn't want/need it.
• Some random types used in packets are defined in the types module, but they are unrelated to each other and don't really belong together. It also feels strange to import them from valence::protocol in user code, so they should probably be re-exported in the appropriate locations.
• Code generators are split between valence_protocol and valence.
• Packets are bidirectional while also trying to be as zero-copy as possible. This means sprinkling Cow around randomly even when we don't really need it.

What solution would you like?

• Define packets in the valence modules where they're actually used. This should be doable because packets aren't really shared between different contexts. This makes sense with #296.
• Tweak the packets to suit the context where they're actually used.
• Get rid of valence_protocol and move top-level modules like text and ident into valence, also at the top level.
• Move Encode, Decode and the packet encoder/decoders to the packet module in valence.
• valence_protocol_macros becomes valence_macros.
• Make the packet inspector depend on valence.
• Introduce encryption and compression features to valence.
• Move the packet enums into packet_inspector.

What alternative(s) have you considered?

There are some problems that may make us want to avoid doing this at all:

• Increases compile times. This can be solved by moving large modules into appropriate subcrates. Think valence_connect, valence_command, valence_inventory, valence_anvil, etc. This can happen transparently by introducing valence_core to avoid circular dependencies.
• Utility crates like the packet inspector drag in more dependencies. Meh, whatever.

Additional context

[misterghast]

How exactly would a server that uses Valence even function without some kind of access to the protocol/packets? It just makes sense to merge them, honestly. I can't think of a use case that wants one but not the other.

[AviiNL]

How exactly would a server that uses Valence even function without some kind of access to the protocol/packets? It just makes sense to merge them, honestly. I can't think of a use case that wants one but not the other.

The packet inspector for one only uses protocol without the need for valence itself. So proxying would be a valid use case, Although I do agree that it would probably fit better in the main project. Probably making things a lot easier in the long run.

[dyc3]

The reasons you've presented here are compelling to merge valence and valence_protocol. However, I do not think that that is a good idea given the current state of the rust compiler. I have personally noticed a fantastic boon to productivity since the separation of valence and valence protocol because of the caching tnat is now possible.

We should most certainly have a central crate to define the structure of all Minecraft protocol packets. It will save a ton of dev time compiling in general, because caching. There is a reason that bevy has their packages separated as they currently do, and I think there is merit in that. Compile times do matter, and I audibly groan whenever valence protocol shows up when I'm compiling.

Ultimately, what I think we should focus on is to define what exactly should valance protocol cover.

[rj00a]

I didn't really make this clear, but I'm not suggesting that we keep everything in a single crate. What I'm trying to do here is make valence's modules self-contained so we can draw clear divisions between them. This includes the relevant packets used in each module.

We could then make these modules separate crates if we wanted:

• valence::inventory
• valence::entity
• valence::player_list
• valence::instance
• valence::client
• valence::weather
• valence::connect (for the login stuff and initial packet handling)

The fact that they're in separate crates would be completely transparent to anyone using the main valence crate. We could also put the modules behind feature flags.

Also note that the poor compile times from valence_protocol is mostly caused by the block state code generator creating way too much code. The situation won't be any worse when it's moved to a valence::block crate.