[databind#4849] Allow standard defaultTyping with EnumSet<E>

[JooHyukKim]

resolves #4849
possible backport to 2.17

[cowtowncoder]

@JooHyukKim Thinking this through, I don't think this is a proper fix, even tho it works around the specific failure here. I'll elaborate on the issue itself, but I think the problem may have been introduced by #4214 (in 2.17.0). Problem for tested case specifically is that customized DefaultTypeResolverBuilder forces addition of type information for EVERY type (for whatever reason), due to:

            @Override
            public boolean useForType(JavaType t) {
                return true;
            }

Or, it should. But while EnumSetDeserializer now expects polymorphic type id for EnumSet AND every Enum contained (... why is this desired?), I think EnumSetSerializer does not write said type id. And I guess it should.

[JooHyukKim]

Ah okay. Let's hold this for now. Will read through ur comment later.

[cowtowncoder]

I committed my changes but it's very much work in progress. Too tired to continue for today, will pick up tomorrow :)

[cowtowncoder]

Ok: change the fix the way I think it might work -- solves the round-trip case, but serialization is different as type ids included for enum values.
But also now fails one earlier test; will try to figure it out tomorrow.

Might also consider opposite path of sort of undoing #4214 in part, maybe -- such that contents (Enums) of EnumSet would never have type id.
But in a way that still allows 4214 case to work.

[cowtowncoder]

Ah ok. So the problem wrt #4214 -- after removing expectation of deserializer expecting type id -- is this:

1. When serializing EnumSet value declared as plain Set, regular CollectionSerializer is used, NOT EnumSetSerializer -- and CollectionSerializer includes Type Id for contents if so requested. Whereas EnumSetSerializer won't.
2. But... Polymorphic type is still recognized as EnumSet, so type id for Collection itself is included
3. Due to (2), correct deserializer -- EnumSetDeserializer is used. And that will now not expect Type Id (since matching EnumSetSerializer would not add it).

So. Need to think of possible way to suppress Type Id inclusion for elements even with CollectionSerializer. Might need to resort to bit of hack, even :)

[cowtowncoder]

Changes needed bit too risky for a patch, moving target to 2.19.

[JooHyukKim]

@cowtowncoder great work!

[JooHyukKim]

Suggested change

	* @since 2.18.3
	* @since 2.19

[JooHyukKim]

For 3.x version, would it be worth the effort trying to find other way instead of this?
And also parts with below code

// [databind#4849]/[databind#4214]: need to check for EnumSet
        final TypeSerializer typeSer = (_maybeEnumSet && value instanceof EnumSet<?>)
                ? null : _valueTypeSerializer;
                

[cowtowncoder]

If there is a way, sure, it would be great to get rid of this work-around.
But I am not sure how, considering the problem itself and how it occurs.
That is: I do not know how this could be avoided at all, regardless of compatibility concerns.

[cowtowncoder]

Ok. So, fix is quite ugly, but I cannot think of a cleaner way to achieve this.
Basically we get "wrong" serializer (CollectionSerializer) in cases where nominal type is not EnumSet, and need to make CollectionSerializer aware of having to skip inclusion of type id for elements for case where collection happens to be EnumSet.

There was discrepancy b/w serialization (was not adding type id) vs deserialization (was expecting type id) in some cases. So, fix was also to remove earlier (#4214) changes that added type id handling for EnumSetDeserializer).

And why is type id not needed/wanted? Because for polymorphic typing we already have parent type id identified as something like java.util.EnumMap<EnumType>; anything else is redundant.

Will merge into 2.19 due to somewhat extensive change; basically changes serialization of EnumSet in some (hopefully rare) cases. So while new mechanism works better, there could be interoperability issues and there's no real way to avoid this.