instead, just ungate this and allow the provider to decide what to do.
Any chunk that contains entities or tiles is already always considered dirty, so the only thing the flags are good for is flagging chunks that previously had tiles and/or entities but no longer do.
In those cases, it's just removing keys from LevelDB anyway, so it's already very cheap.
Avoiding these redundant deletions is not worth the extra complexity and fragility of relying on flags to track this stuff.
a non-generated chunk is now always represented by NULL. This forces the case of ungenerated chunks to be handled by all code, which is necessary because ungenerated chunks cannot be interacted with or modified in any meaningful way.
in cases like PopulationTask it makes more sense to store the coordinates separately where they can be stored more efficiently (once instead of 9 times)
In addition, PopulationTask shouldn't need to serialize an empty chunk just to copy coordinates.
I've made changes like this in other areas already in preparation for the day when chunks no longer contain their coordinates, so this brings us one step closer to that goal.
I think we should probably get rid of this considering the potential for inconsistencies within a chunk, but not retaining this is a bug nonetheless, even though it doesn't have any effect in PM itself since we always use BlockLegacyIds << 4 as the empty block ID.
so, this is only really aiding (ab)use cases which weren't intended anyway ...
this produces a major performance improvement for large render distances, and reduces the impact of lighting calculation to zero on servers which have random blockupdates turned off.
copy-on-write and zero-layer SubChunk objects are much easier to manage and have less cognitive overhead.
obviously, the goal is to get rid of EmptySubChunk completely, but right now it does still serve a purpose (filling in dummy values for reading out-of-bounds on chunks), and that's a problem that takes a little more work to fix.
