[Bug]: Persisting BE update tags in contraptions breaks BEs with optimized networking

[XFactHD]

Description

To optimize packet size, Create's contraptions send the update tag of the contained BEs to the client instead of the full BE tag. Since loading a contraption from disk does not re-create the BEs, this update tag is persisted across reboots. For most BEs this works fine (or at least appears as such). When a custom BE however employs network optimizations of its own such as sending BlockStates via their int ID (which is not guaranteed to be stable across server reboots), then this falls apart with potentially catastrophic results. To mitigate the potential of chunk banning, FramedBlocks uses BlockState IDs and other integer registry IDs when serializing the applied camos for networking. Combined with the instability of int ID mappings across reboots and Create persisting data that is only intended for networking, this causes issues where framed blocks on Create contraptions sometimes display with completely different camos after a server reboot: https://github.com/XFactHD/FramedBlocks/issues/617.

Potential Solution

After discussing this issue with @PepperCode1, one potential solution that came up is to provide a Block or BlockEntityType tag which is used to mark BEs whose update tags cannot be persisted and require the full BE tag to be sent instead.

Versions

NeoForge: 21.1.164 Create: 6.0.4 FramedBlocks: 10.3.1