Better handling for request message with oneofs

[timw]

Is your feature request related to a problem? Please describe.
When constructing a request message, it's not always entirely obvious which fields can/need to be populated.
This is particularly the case where the request message contains oneof elements, which is a common pattern in some APIs that take an ADT type approach to some operations (e.g. a search method that can take one of a finite set of query objects).
The defaulting, and autocomplete works pretty well for simple messages, but when oneof is used, it becomes much less obvious:

• it's not possible to view the entire message schema to get an overview of the overall message structure and options
• the request editor currently allows multiple of the oneof elements to be specified in the JSON
• (related) the autocomplete doesn't indicate which fields are part of a oneof

In my current case, I'm using gRPC reflection to load the available API definitions, so the protobuf isn't readily available.

Describe the solution you'd like

• A schema tab on the request pane (either at the top level, or a bottom tab on the existing Request tab) that showed the full request message schema would be useful.
• A UI affordance (e.g. a gutter decoration or some other kind of decoration) where a oneof is being used in a message would help inform whether that could be overridden.
• Grouping of oneof options in the autocomplete:
  ** Show the actual name of the oneof (and indicate it is a oneof with a decoration) as well as the field options contained in it
  ** Allow one of the options to be chosen
  ** Exclude the oneof (and sub-options) from the autocomplete when an option is already present in the message
• Replacing a oneof option would be as simple as removing it from the message and then using autocomplete to insert another one (with the decoration indicating it's a oneof informing the user that there are other options available).
• Decorating the use of oneofs in Response messages would also be useful for understanding the response, but not as important as requests.

Describe alternatives you've considered
I can always extract the protobuf schema from the reflection API, or obtain from another source, but having it integrated in the request experience would be much easier to manage.

Additional context

[CommonGuy]

Thank you for your suggestions, they definitely make sense.