Support `(set_once)` in validation codegen

yevhenii-nadtochii commented 3 weeks ago

This PR extends coverage of validation codegen to support (set_once) constraint.

The option is enforced by checking (during a field value assignment) that the current value is either default for the field type OR it is the same with the assigned one. Otherwise, the validation exception is thrown right away.

When one or more fields with the message are marked with the option, the following groups of methods are modified to add the precondition checks:

All set...() methods for the marked field.
All merge...() methods, except for AbstractMessage.mergeFrom(final Message other). In merge methods, only parts relevant to the marked fields are affected.

`AbstractMessage.mergeFrom(final Message other)`

This method is not explicitly supported, though it might be workable.

Supported field types

All primitives, enums and messages are supported.

An attempt to mark repeated or map field leads to an exception.

yevhenii-nadtochii commented 3 weeks ago

@armiol @alexander-yevsyukov

We should settle down on the option specification before proceeding with this PR. I've examined the generated code, and the main disappointment is that Protobuf v3 doesn't store explicit information about whether the field was set (except for optional fields). Our implementation checks that the current field value is default for the field type, only then allowing a new one to set.

In general, Protobuf builders provide three paths to modify the message.

set...():

Direct field setter like setName(String name).
Alternative setters like setName(ByteString name) for string and setMyEnumValue(int value) for enums.
Direct field setter that accepts a builder instead of a message (only for message-based fields) like setStudent(StudentBuilder builder).
Reflective setter, which sets a field by its descriptor setField(FieldDescriptor, Object).

merge...():

Field merging (only for message-based fields) like mergeName(Name value).
Message merging mergeFrom(Student other).
Bytes merging mergeFrom(byte[] data).

clear...():

Clear a specific field clearName().
Clear the whole message clear().

The questions are the following:

Should we allow a custom error message for this option?
Which field types are supported? - I suggest messages, enumerations and all primitives excluding repeated fields and maps. bytes arrays are also allowed.
Which points of message mutation does the option cover? – All setters for sure. But should we cover merging and clearing? The current implementation implicitly covers because it just compares a field value having two message instances. The problem is that for many field types, the merging is based on setters. We have to overcome this. And clearing allows overriding a field value, for which (set_once) is specified.
Should we allow the field to be set to the current value? – Looks logical if we cover merge-based mutations. Looks safe for setters as well.
Should we prohibit clearing of a specific field if it is marked with the option? What about the builder clear() then? – I suggest considering merge and clear service methods, and don't touch them at all. Only fix the fact that for some types, merge redirect to setters. We can introduce private unsafe setters for that, for example.