Drop oneof with sealed classes

[Egorand]

We won't be going forward with this design, so the plan is to go back to the strategy we use in Java codegen. Since we already use it in interop mode, we should just make it default and remove the sealed classes approach.

[kirillzh]

@Egorand, out of curiosity, why was it decided not to generate sealed classes for oneof protos?

[Egorand]

@kirillzh they didn't prove to be a good idea in practice and we had cases when they didn't make much sense. However, I'd like to re-evaluate this decision at a later point. CC @swankjesse

[swankjesse]

It means you end up needing to box things because the types in the oneof aren’t necessarily unique or defined locally.

[linakis]

@swankjesse isn't the same true for swift enum also though? I believe that exhaustiveness benefits are far too good to discard. Isn't having the compiler guard you against proto changes and not relying on runtime checks the whole point of having a contract in the first place?

[JavierSegoviaCordoba]

I think adding a flag to allow both solutions should be great. Is it possible @Egorand?

[sanggggg]

Any further progress on this issue?

Although oneof as kotlin sealed class can cause verbose class wrapping & inconsistency with java codegen, sealed classes still seem to be a good option for compile time type checking.

It would be nice to have an opt-in support for this.