[1.21.3] Implement support for preventing effects from being removed by milk or totems

[XFactHD]

This PR replaces the hard-coded consume effects on milk and totems such that mods can prevent their custom effects from being cured by milk and totems respectively. The honey bottle is left out intentionally as mods can use the ModifyDefaultComponentsEvent to add additional RemoveStatusEffectsConsumeEffects for their effects to the DataComponents.CONSUMABLE component specified on honey bottles.

To achieve this, the ClearAllStatusEffectsConsumeEffects are replaced with RemoveStatusEffectsConsumeEffects holding a NotHolderSet that wraps a blacklist tag.
Since these changes are applied to the item's "component prototype", the changes won't be synced to a non-NeoForge counterpart and should therefor not cause any issues or desyncs there.

This PR is the replacement for the defunct EffectCure system.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

Last commit published: fa8261547e16da956fdb12235198e905ce5dfab4.

PR Publishing

The artifacts published by this PR:

• 📦 net.neoforged:testframework:21.3.17-beta-pr-1603-effect_curing
• 📦 net.neoforged:neoforge:21.3.17-beta-pr-1603-effect_curing

Repository Declaration

In order to use the artifacts published by the PR, add the following repository to your buildscript:

repositories {
    maven {
        name 'Maven for PR #1603' // https://github.com/neoforged/NeoForge/pull/1603
        url 'https://prmaven.neoforged.net/NeoForge/pr1603'
        content {
            includeModule('net.neoforged', 'testframework')
            includeModule('net.neoforged', 'neoforge')
        }
    }
}

MDK installation

In order to setup a MDK using the latest PR version, run the following commands in a terminal.
The script works on both *nix and Windows as long as you have the JDK bin folder on the path.
The script will clone the MDK in a folder named NeoForge-pr1603.
On Powershell you will need to remove the -L flag from the curl invocation.

mkdir NeoForge-pr1603
cd NeoForge-pr1603
curl -L https://prmaven.neoforged.net/NeoForge/pr1603/net/neoforged/neoforge/21.3.17-beta-pr-1603-effect_curing/mdk-pr1603.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zip

To test a production environment, you can download the installer from here.

[neoforged-automation]

@XFactHD, this pull request has conflicts, please resolve them for this PR to move forward.

[KnightMiner]

This PR is the replacement for the defunct EffectCure system.

This is an incomplete replacement. You handle the part of the effect cure system that allows making an general mob effect type not curable by milk, but don't handle the part of the system that allows making specific effect instances not curable.

For instance, I have a mod that adds effects in a mutually exclusive system that uses effect cures to ensure that adding one effect from the set removes the others. However, I also have some vanilla effects in this system, which is easy to accomplish by setting the effect cures on the effect instance before applying it to the player.

The only way to accomplish the same thing with this proposed system would require me registering additional copies of vanilla effects, which based on the effect may not scale properly (not to mention the UX mess if you have both the copy and the original at the same time)

[XFactHD]

It's the best we'll get, unfortunately. NeoForge must preserve network compatibility with vanilla and therefor can't register a custom consume effect, which means we're restricted to ClearAllStatusEffectsConsumeEffect and RemoveStatusEffectsConsumeEffect. The former just clears everything and the latter only supports a HolderSet<MobEffect>. There is no way to provide control per effect instance.
It's also worth noting that the effects now in general have very little control over whether they can be cured or not, this is basically entirely up to the consumable items now.

[Shadows-of-Fire]

@XFactHD Have you validated that this is network compatible? I had someone mention to me that changes in the default component set of an item are not network-compatible either, which would make this not a viable solution.