Feat: scala3 enumeration support

[ThijsBroersen]

With this PR I have tried to implement Scala 3 enumeration support. Because the current macros already do some assumptions and are build with Magnolia I did not want to disrupt to much and tried to implement it under the following condition:
If all subtypes are named values (objects without parameters) then the type is an enumeration.

This means that if an enum has mixed children, with and without parameters, then the implementations stays the same. Only for pure enumerations (all named values) the encoding/decoding will be affected.

Breaking:
To my opinion the current implementation is wrong as enumerations are normally serialized as strings. But this PR will of course be breaking for the few using zio-json with Scala 3 enumerations already.

I deliberately did not try to implement this for Scala 2 as these are not native enumerations.

[ThijsBroersen]

This static encoder make it possible to filter on at L625

[ThijsBroersen]

I chose to use this hack because I don't think I have access to the ctx.params of the subtypes here anymore.

[ThijsBroersen]

Interesting, so it seems shared specs are now failing because in Scala 3 the sealed traits are now also treated as enumerations. 🤔

[ThijsBroersen]

Interesting, so it seems shared specs are now failing because in Scala 3 the sealed traits are now also treated as enumerations. 🤔

Fixed 🙃

[fsvehla]

It’d say let’s get it in, the next version will be a new 0.x.
Do you have a few cycles to add some docs?

[ThijsBroersen]

@fsvehla I was just trying to update the docs but this docs modules is Scala 2.13 only. Can Scala 3 be mixed in?

[ThijsBroersen]

@fsvehla I did one more attempt:

• added docs with non-mdoc Scala 3 code-blocks
• adjusted the implementation to also treat sealed family (where all members are objects) as enums

The tests now fail with the GoldenSpec which assumes sealed families with only object members should be encoded as objects...
I don't agree with the spec as many libraries, including Tapir, encode this as string-based enum. When using Tapir this would lead to an endpoint schema which renders an openapi spec saying the type is a string-based enum and a json codec which behaves differently.

What is your view on this?

[fsvehla]

@ThijsBroersen I agree that the proposed change makes sense for most cases (and takes care to exclude enums containing case classes). Fine to remove that test!

[ThijsBroersen]

Changed the golden-test SumType.Case3 from case object Case3 to case class Case3(). Now it is derived as non-enum and the test works as expected. So this PR will change sealed traits / enums where all cases are without constructors, these are now derived as string-based enums.

[ThijsBroersen]

Lets merge!