proto: revert UTF-8 validation for proto2

[dsnet]

The proto specification officially says that proto2 and proto3 strings should be
validated, but pragmatically, compliance with the spec has been poor.
For example, the Go implementation did not validate either and added strict
validation recently to be compliant. However, this caused signficant breakage.

Cases of breakage should change the proto field type from string to the bytes type.
However, this is not always possible, when the field is part of the exposed API.
This tends to be the case for proto2, where some other notable language
implementations (like C++) do not validate proto2 for valid UTF-8.
However, since most language implementations do validate for UTF-8 in proto3,
we keep that behavior.

Making this change for Go is a little tricky since each field does not necessarily
know whether it is operating under the proto2 or proto3 syntax. Thus, we modify
the generator to emit a "proto3" struct field tag for all fields in proto3.
The implications of this change is that people will need to regenerate their
proto files to have UTF-8 validation.

We expand UTF-8 validation tests to ensure this works for the cross-product of
(proto2, proto3) and (scalar, vector, oneof, and maps) fields with strings.

Fixes #622

[neild]

Should we export errInvalidUTF8?

[neild]

Should this use the "proto3" tag instead? We may discover other cases in the future where proto2/proto3 fields need different handling, and it'll be more efficient to have a single tag in that case.

If so, should we preemptively tag all proto3 fields, even if they currently have no semantic difference?

[dsnet]

The proto3 tag was already added to distinguish the semantic difference for []byte{} vs []byte(nil) when it comes to the bytes type.

Looking through the code history, the attribute was only generated on the bytes type out of fear for binary size increase. If we want to go with proto3, should we just generate it for all fields? That's an increase of 7 bytes for every field. Alternatively, we can only generate it for the string field.

[neild]

If we're worried about binary size increase that argues for a proto3 tag rather than utf8, to avoid the possibility of redundant tags in the future.

I don't really have a strong opinion on every field vs. string, although there are a couple arguments for the former: It avoids any possibility of needing to do this again in the future, and I think all the cases where 7 bytes per field might conceivably be an issue are proto2 anyway.

[dsnet]

I enabled it unilaterally for all fields.

[dsnet]

Let's avoid exporting the error for now.

Several thoughts:

• As it stands the current logic fails-fast when there is invalid UTF-8. In order for a distinguishable error to be useful, they would still need to fully marshal or unmarshal the message.
• We probably wouldn't want a sentinel error. A useful piece of information is the exact field that had UTF-8 error.
• If we exported a new type, then we have to think carefully about what happens message has both required fields not set and invalid UTF-8. You would probably want to report that both errors occurred. Here's a case where your error tagging idea would be really useful.