lib/proto: Allow replacing repeated fields, instead of appending.

[WojciechP]

Consider the following Stralark line:

    msg.repeated = [1,2,3]

Without this commit, that line appends three elements to the previous existing repeated values. With this commit, that line replaces the previous repeated values with new three items.

I believe the old semantics is simply a bug, and that most users would expect an assignment to overwrite the previous value.

[adonovan]

Thanks for pointing out this bug, and for the fix.

I realize it would be cheeky of me to suggest that a CL like this might benefit from a test, but if you plan on investing in this package it would be worth your time to build one sooner rather than later.

[WojciechP]

I realize it would be cheeky of me to suggest that a CL like this might benefit from a test, but if you plan on investing in this package it would be worth your time to build one sooner rather than later.

Asking for tests is never cheeky :)

I added a small test for this, although there is number of choices to make, and I tried to choose reasonably:

• Where should that test be? One could argue that within lib/proto, but the simplest way was to extend the existing tests by adding another .star file in starlark/testdata, so I did that.
• Where to get a proto descriptor for the test? Running protoc as part of the test seemed excessive, so I decided to use protoregistry.GlobalFiles and link against FileDescriptorProto itself.

I agree that if we are to make more use of the lib/proto module, it deserves a more comprehensive test suite. For the time being I think this is a good start to accompany the one-line fix.