Extend Data Attachment API to ProtoChunk

[jacobsjo]

This PR extends the Data Attachment API to allow data attachments on ProtoChunks, rather than just WorldChunks. Data on a ProtoChunk is kept when it is converted to a WorldChunk. This allows storing custom data during worldgen and reading it during gameplay.

Individual changes:

• Move the interface injection from WorldChunk to Chunk.
• Transfer the attachment of a ProtoChunk to a WorldChunk in the WorldChunk constructor.
  • I've reused the copyOnRespawn helper method for that and renamed it to transfer to better match its extended use.
• A separate mixin to WrapperProtoChunk that simply forwards the calls to the wrapped WorldChunk.

What still needs to be decided:

• Should WrapperProtoChunk.setAttached adhere to the propagateToWrapped flag? -> We ignore the flag and always write to the WorldChunk.
• What should happen when trying to attach a persistent attachment to a ProtoChunk with chunk status EMPTY? Since those aren't saved, the attachment would get lost too. Options are:
  • Save empty ProtoChunks when an attachment is present. (I would still need to investigate how to do that.)
  • Throw an exception when trying to attach a persistent attachment (but allow non-persistent attachments).
    -> We log a warning. The javadoc documents this behavior.

Tests:

I've extended the testmod to test saving data to a ProtoChunks.

• A custom configured feature that writes an attachment to the ProtoChunk if it is in the [0, 0] chunk, then testing whether the attachment is present in the WorldChunk after world-load. This tests both writing to ProtoChunks and the WorldChunk conversion.
• To test persistence in ProtoChunks, I'm adding an attachment to a far chunk. This requires this chunk to not be generated beforehand.

[Syst3ms]

Code looks good so far. I don't know too much about how worldgen and chunk code works, so I'm unsure about the design decisions to make. I'd have someone else weigh in on this.

For propagateToWrapped, if that field is named intuitively, it would make sense to always attach the data to the ProtoChunk, and also attach it to the wrapped chunk depending on the flag.

I don't exactly know what EMPTY ProtoChunks correspond to, but I'd suggest simply emitting a warning when trying to use a persistent attachment. An exception is overkill, and manually saving such chunks feels like an intrusive change for no reason.

[jacobsjo]

To elaborate further on the 2 open questions:

The propagateToWrapped flag is basically always false, so the question is rather whether WrapperProtoChunks should allow setting attachments at all.

There are basically 2 use cases for writing attachments to ProtoChunks: The first use case is writing to the currently generating chunk during worldgen. For this case, neither of the 2 open questions matter, as we never deal with WrapperProtoChunks, nor with chunk status EMPTY. Maybe you'd want to write to neighboring chunks, but even then you
probaby won't encounter a WrapperProtoChunks unless someone was manually pruning chunks. In that case it might be confusing if setting blocks is silently ignored but writing attachments is allowed.

The second use case is saving to chunks at arbitrary positions, i.e. writing something like:

overworld.getChunkManager().getChunk(x, z, ChunkStatus.EMPTY, true).setAttached(...);

If we want to support this use case (and I could very well live with a "no" to this questions), then the questions become more relevant:

• Writing to ProtoChunks with EMPTY chunk would be helpful, but just exchanging EMPTY with STRUCTURE_STARTS (the very first actual generation state) just works without changes. (And is what I currently do in the testmod)
• Writing in WrapperProtoChunks would be helpful as then you don't need to differentiate between chunks that are fully generated and those that aren't

[jacobsjo]

I've extended the testmod to include a direct test of writing to protochunks during worldgen, which is the main use case of this PR.

[Syst3ms]

Writing to ProtoChunks with EMPTY chunk would be helpful, but just exchanging EMPTY with STRUCTURE_STARTS (the very first actual generation state) just works without changes. (And is what I currently do in the testmod)

That sounds like a decent solution, please document it in AttachmentTarget in an extra section. Don't forget to also update the references to WorldChunk that are already present.