Support reserved names in ProtoJSON deserialisers

[Grimeh]

What language does this apply to?
My particular use case is in Go but it applies to all languages that implement ProtoJSON.

---

Describe the problem you are trying to solve.
Currently if a field is removed from a message, this is a wire-safe change for the binary serialiser (the field will be discarded by the deserialiser) but will trigger a parsing error for ProtoJSON.

That is, unless the "discard/ignore unknown" deserialiser option is enabled. However this will cause ALL unknown fields to be silently discarded. Which is a shame because the default behaviour is still desirable for truly unknown fields.

It's already possible to reserve field names with the reserve keyword, and the docs state that TextProto implementations may recognise this and discard unknown fields if it's a reserved name. The same docs also state "Runtime JSON parsing is not affected by reserved names.".

---

Describe the solution you'd like
It would be ideal if ProtoJSON implementations respected reserved names, by discarding unknown fields if they match a reserved name. This way it's possible to remove a field and have it safely deserialised by both binary and json implementations, as long as the field name is reserved. Truly unknown fields (not defined or reserved) still result in a parse error by default, catching actual errors ASAP.

NOTE: I am not requesting that unknown fields are preserved by ProtoJSON impls. The lack of preservation of reserved fields is completely acceptable (and even desirable imo).

---

Describe alternatives you've considered
The alternative (more of a workaround) is to enable the "discard unknown fields" ProtoJSON deserialiser option everywhere that could be affected by a removed field in the future (which is pretty much everywhere). As mentioned above this is bit of a sledgehammer fix and significantly weakens the safety checks of the deserialiser, which I'd like to avoid if at all possible.

Another alternative is to leave the field in the message definition and change the field doc comment to something like "OBSOLETE DO NOT USE", however this is confusing and easy to miss.

---

Additional context
Example:

Version 1

message MyMessage {
    string name = 1;
    string city = 2;
}

Version 2

message MyMessage {
    reserved 2;
    reserved city;

    string name = 1;
}

This is a wire-safe change for the binary deserialiser, but it will cause the ProtoJSON deserialiser to fail with a unknown field "city" error. Ideally the "city": "my city" field would be discarded since the name is reserved (and thus "known").

Previous discussions around this (eg. #3440) mostly centred around the discrepancy between the binary & json deserialisation with default settings. I couldn't find an issue specifically around accounting for reserved names in ProtoJSON deserialisation.

[esrauchg]

I agree with the premise of the feature request, and that it is a weird historical quirk that this was done in TextProto but not JSON.

It's a somewhat borderline case but I think unfortunately we see making this change as a breaking change on the JSON wire format, because what would happen is if we made the new rule that it should behave this way, new runtimes could parse data that other runtimes would parse-fail on. Even more minor distinctions than this has caused us a lot of headaches in the past when e.g. someone wants to rewrite from language X to language Y they basically never expect that comes with a difference in what inputs will parse-fail or not.

Going forward the way we expect to handle topics like that is to change the behavior under new Editions. Because every runtime has to affirmatively say it supports the new Edition number, you can add behavior in a new Edition without it being an ecosystem break. Essentially Proto3 would never support it, and some Edition 202X would add the new behavior (and have a feature which disables the behavior so that you can safely upgrade Proto3 files with no semantic impact).

It's a bit heavyweight ethos though: you have to add the new behavior and make sure its only on for new Edition files, and apply that to all runtimes that we care about. It unfortunately fails to ever deliver new behavior to users who are stuck on Proto3 (which is in a sense exactly the working-as-intended tradeoff because the whole topic of concern is 'new behaviors are breaking behaviors, and we don't break Proto3'). It also unfortunately makes any such new behaviors into 'long term plays' and never immediately landed things.

So I think basically this is a candidate for future Edition behavior, but may be difficult to justify the implementation costs.