Add *Record ProtoBuf messages and corresponding serde functions.

[panh99]

• Defined 6 new messages in a new file recordset.proto
• Wrote serde functions for the new messages
• Added unittests accordingly.
• Updated the test_proto_file_count (b/c we now have 6 proto files)

[danieljanes]

MetricsRecord only allows int and float types (and lists of those two types)

[panh99]

Yes, I get it.
I was thinking that, since we enforce type checks when instantiating the MetricsRecord, which means the data field inside must be valid, we can reuse Value to store them to avoid having repetitive code in proto files and in serde.py. But I also happy with copy-pasting part of the serde functions for Value and create new messages for MetricsRecordValue.

[danieljanes]

Got it, makes sense. I suspected that to be the case :)

My recommendation would be to create new messages that map closely to the Python code for two reasons:

1. Enable us to remove Value once we migrated everything to RecordSet
2. Make it easier to implement non-Python clients based on the ProtoBuf definitions

[danieljanes]

ConfigsRecord doesn't allow bool yet. That's sth we should fix in a separate PR by adding it to ConfigsRecord.

The more general question: should we define ProtoBuf messages that follow the same naming scheme as their Python dataclass counterpart?

[panh99]

The reason for reusing Value instead of creating a new message ConfigsRecordValue is the same as above (MetricsRecord).

Re: naming. IMO, we should use different names or even store them in a different way in a TaskIns. There's no benefits to keep them strictly equivalent. I think the ProtoBuf messages is aimed solely to transfer contents over the wire, which is different from the purpose of introducing record types. And hence I think we don't need to follow the same naming scheme and even don't need to have a counterpart for each dataclass record.

The advantage of not having counterparts is that we may not have to change protobuf messages and serde functions accordingly when we decide to modify our RecordSet. The disadvantage is that it's not easy to design a protobuf messages for general uses, and the naming will be less intuitive if we allow users to change protobuf messages in the future.

[danieljanes]

I agree that we do not need to aim for a strict 1:1 mapping from Python to ProtoBuf.

I do think however that there is an advantage to keeping them close. As stated in the other comment, we want to implement Flower clients in languages other than Python. This usually starts with compiling existing ProtoBuf messages. If those messages are close to the Python level, it will be easier for others to implement the Java/C++/... counterpart.

In addition to that, it will maintenance of the Python client easier as well. In the case of MetricsRecord, for example, we would not need to check for unsupported Value types if we have a MetricsRecord on the ProtoBuf level that supports the exact set of types that the Python MetricsRecord supports.