[Android][0] and [Desktop][1] have already removed this field. This
follows suit.
The highlights:
- `SignalService.proto` removes some fields by making them `reserved`
- `ProtoWrappers.py` updates our code generation to support addresses
that only have a UUID (previously, you needed both a UUID and E164
field)
- Most everything else is removing E164s
[0]: 9c266e7995
[1]: 2b0d3cab40
_This change should have no user impact._ And you can see that the only
changes to generated files are in comments.
Before this change, we used comments to denote reserved or deprecated
fields. This works, but I think we should instead use the `reserved`
keyword, which offers a few advantages. From [the protobuf docs][0]:
> If you update a message type by entirely removing a field, or
> commenting it out, future users can reuse the field number when making
> their own updates to the type. This can cause severe issues if they
> later load old versions of the same .proto, including data corruption,
> privacy bugs, and so on. One way to make sure this doesn't happen is
> to specify that the field numbers (and/or names, which can also cause
> issues for JSON serialization) of your deleted fields are reserved.
> The protocol buffer compiler will complain if any future users try to
> use these field identifiers.
This updates our proto files to use `reserved` instead of comments. It
also adds support to our wrapper script. (I moved a few things around in
that script, too, for consistency.)
I think this is a useful change on its own, but I think it'll make
things a little better when we deprecate some fields, which we're
planning to do soon.
[0]: https://developers.google.com/protocol-buffers/docs/proto3#reserved
We expose many of these builders to Objective-C, but Swift is unable
to map forward-declarations of those types (@class) back to the real
Swift classes because they're nested within the protos. Since we're
already using fully-qualified names even in Swift (e.g.
"SSKProtoContentBuilder"), nesting isn't worth the trouble it's
causing.
Shaves off about 20% of a deep serialization benchmark (that's
unfortunately using code that isn't checked in yet).
Also removes Equatable from oneof enums, which wasn't really doing the
right thing anyway when there were non-primitive payloads because the
proto classes didn't override isEqual.
The Swift compiler ought to be smart enough to prove that
copy-out/mutate/copy-in is the same as mutate-in-place for structs,
but it currently isn't clever enough to do that.
(See https://bugs.swift.org/browse/SR-11895.)
