[protobuf-go] Add new feature - ignore field when Marshal message

[Mahes]

Is your feature request related to a problem? Please describe.
I have a project which it has grpc interceptor that log every request and response. Meanwhile in current changes, i added a new sensitive field which i do not want to print that field into the log. I do some research and found that proto3 has a tag called json_name. But unfortunately it only generates the proto3 json tag that can only be used by jsonpb / protojson. Also it's still not working as json: -,omitempty , it's still printing the field as "-".
Example:

{
    "customer": {
        "name": "david",
        "-": "2324238472344"
    }
}

Describe the solution you'd like
I want to suggest while reading the fields, if json_name is set and the value is "-", ignore the field and do not Marshal it. Hence the result will be:

{
    "customer": {
        "name": "david"
    }
}

Describe alternatives you've considered
Alternative i can think is i can make a custom json encoder, and have a list of field names that will be skip/ignored when marshaling the struct. But IMO this is not a proper way because i need to define new field twice. 1 in the proto file, and have it listed as ignored field in the code if i don't want to log the field.

Additional context
I want to contribute the feature myself. I have read the guidelines, but i'm not sure if i can do it, because usually i'm using yahoo instead of google email for github.

[Cassondra Foesch]

So, the JSON mapping used by protojson and jsonpb is part of a common protobuf standard, which does not provide the ability to skip or ignore a value during marshalling when the json_name struct tag is set to anything, because C++/Java/Python/etc do not typically have struct tags, that can be used like in Go. Since such a feature would remain a Go-only feature, it is not something that will be considered to be added into the package, even if you were to provide a contribution yourself.

However, there has been discussion on this topic before, and you can feel free to continue the discussion there.

(As this is a duplicate of another issue, and the core proposed feature is non-viable, I will be closing this issue.)