Skip null fields in ProtoBuf serialization

[bezmax]

Defaults to skipping null fields during Protobuf serialization. Resolves issue #71 .

The issue blocks any real usage of kotlinx.serialization, as there is no way to serialize an optional field as of right now. I suggest this as an easy and mostly-compatible fix until a long-term solution is devised.

The only real problem I can see with this approach is this:

data class Message(val a: String? = "foo bar")
...
val msgIn = Message(null)
val bytes = ProtoBuf.dump(Message.serializer(), msgIn )
val msgOut = ProtoBuf.load(Message.serializer(), bytes)
msgIn shouldBe msgOut //Fails, as it will become a specified default string.

[sandwwraith]

There's also a bigger problem with primitive types:

data class Message(val a: Int? = 42)
...
val msgIn = Message(null)

If we drop a here, protobuf spec says: when a property of type int is missing, the parser should substitute 0, so a client reading our message won't get null. On the other hand, if someone omits an a value when it is 0, we'll incorrectly insert 42.

However, I completely agree with you that this is a pain point. Your solution works with non-primitive types when default values for properties are null, so it covers plenty of cases, but it is still a workaround.

So I suggest to move it under a configuration flag, like with JsonConfiguration.allowStructuredMapKeys. Since we don't have much configuration flags, separate ProtobufConfiguration seems unnecessary to me, an additional boolean parameter in Protobuf constructor should be okay. Also, it would useful to have documentation for that parameter which describes its shortcomings (basically, our examples where this setting produces an incorrect result).

Also, please re-open this PR against the dev branch.

[bezmax]

@sandwwraith Yes, I know about that issue. Did not mention it as it was already there even before this suggested change. The suggestion actually makes it more consistent now in (incorrect) behaviour.

For example, right now you already can do this:

data class Message(val a: Int = 42) //Not even nullable
print(ProtoBuf.loads(Message.serializer(), "")) //Will be 42, while should have been 0

I see that there's a shouldWriteElement on TaggedEncoder, instead of adding a property I could just implement it correctly just for classes by overriding this method. In that case for scalar types you could still define your fields as val a: Int = 0 and be mostly proto compatible, and for classes it will allow nulls by default - which is also compatible. What do you think about this approach? I'll try to modify my PR for a concrete example of how this would look like.

[bezmax]

Created a new PR against dev with a slightly different (and fully Proto compatible) approach: #591