Feature Request: Replace SimulatedNull code with new protobuf optionals

[mattlord]

Feature Description

In the past the protobuf implementation of "optional" fields and testing for whether or not a field value was actually provided in a message relied on the one of feature which was not fully supported in the go protobuf implementation.

It was for this reason that the SimulatedNull support was added in Vitess and used in some of the new vtctldclient command implementations (all VReplication related): https://github.com/search?q=repo%3Avitessio%2Fvitess%20SimulatedNull&type=code
This was always clunky and ugly but in the past there was no less bad option.

In recent protobuf versions, however, the go implementation does now support the ability to detect if a field was specified/present in a message: https://github.com/protocolbuffers/protobuf/blob/v3.25.0/docs/field_presence.md

With recent versions (3.15+(?), but it was 3.2+ where this support was moved out of the experimental designation) when you mark a field as optional in the proto message definition, the given type becomes a pointer (e.g. string becomes *string). This allows for detection of a value being present as you can then leverage nil for pointers and differentiate from the type's ZeroValue.

We should move all of the SimulatedNull related code over to using this new optional protobuf behavior/feature. Open concerns are:

1. Is adding the optional keyword to trigger this new behavior in recent protobuf versions backwards compatible?
2. You cannot address consts, so we'd need to find a way around that as we often use them in the messages today (e.g. binlogdata.VReplicationWorkflowState)
   • This may change in go 2: proposal: Go 2: make constants and literals addressable golang/go#28681
3. web/vtadmin/bin/generate-proto-types.sh fails with optional fields today
4. optional does not seem to be supported with repeated

We definitely want to make this move as managing the SimulatedNull behavior is a pain and it's too easy to make a mistake (a new field is added in the message and existing callsites are not updated to pass the SimulatedNull value so you get unexpected results/behavior). It's just a matter of when we do this and how much work it will be.

Use Case(s)

Good code?