VanillaBlocks isn't guaranteed to be a complete record. For example, I've considered moving chemistry blocks to a separate EducationBlocks registry.
In such a case, the blocks are still expected to serialize correctly, but they won't be in VanillaBlocks.
this does come at a performance cost, but is necessary for metadata expansion.
we finally concede that this is not going to happen without BC breaks, however small they might be ...
closes#4646closes#4645
Impact assessment by core usage search and poggit suggests that the impact of this change will be close to zero.
However, since it changes behaviour which plugins might be unknowingly relying on, it's going into 4.1 rather than a patch release.
when a block has sole ownership of an ID, the state bitmask can be ignored and we can just claim the whole metadata range for that single block.
This fixes a large number of issues with unknown blocks on older worlds where world editors did not remove the metadata, although update blocks will currently still appear on initial chunk send due to lack of AOT conversion (TODO).
this doesn't implement the server-side logic for the "stickiness" (slowdown) because we don't have the system needed for it yet.
It also doesn't have parity with vanilla on the damage.
while this is a bit hacky outside of the protocol namespace, it makes it much easier to use the protocol library for alternative purposes, such as for a client or MITM proxy.
It also removes all but one remaining core dependency of the protocol library, making it very close to being able to be separated from the server core entirely.
