Add Post Effect API

[Doc94]

This PR add support for the server-side implementation for send/remove post effects.

[GliczDev]

Post effects are order dependent, imo the API should expose something like setPostEffects rather than add/remove methods

[Doc94]

Post effects are order dependent, imo the API should expose something like setPostEffects rather than add/remove methods

True... i just try to mirror the vanillla command, but override the order directly can be good for the API.
added to the PR.

[masmc05]

Wouldn't it make more sense to throw on nulls and dublicates instead of silently ignoring those?

[Doc94]

I try to mirror vanilla and also try to reduce the implementation to just silently remove inconsistences rather than check all the list for Preconditions and save again for send.
and this only cover server-side effects... client can still has a few (like when you spectate a creeper) effects so not sure if is necesary throws rather than non-null list

[masmc05]

and save again for send.

Well with something like

    public boolean setPostEffects(final List<Key> postEffects) {
        Preconditions.checkArgument(postEffects != null, "postEffects cannot be null");
        LinkedHashSet<Identifier> ids = new LinkedHashSet<>(postEffects.size());
        for (Key effect : postEffects) {
            Preconditions.checkArgument(effect != null, "effects cannot be null");
            Preconditions.checkArgument(ids.add(PaperAdventure.asVanilla(effect)), "effects cannot be duplicate");
        }
        return this.getHandle().setPostEffects(ids);
    }

And

+    public boolean setPostEffects(final Collection<Identifier> postEffects) {
+        if (com.google.common.collect.Iterables.elementsEqual(this.postEffects, postEffects)) {
+            return false;
+        }

The resave etc shouldn't really impact anything. Just silently stripping invalid part of the input isn't consistent with other methods in same class like sendEquipmentChange or give

But for clientside behavior you're right that it's indeed a bit different than what command presents, as even ClientboundPostEffectsPacket and its handlers accepts duplicate post effects which should in theory work together, but I still don't think that silent ignore would be good

[Doc94]

okay that looks fine to me... im going to include this.