Improve typing

[TobiasBales]

This bumps the # typed sigil to strict and runs srb tc in test cases.

This means some adjustments to the generated code (or quite a lot).
I would like to get initial agreement on the direction and then would do some clean up (there are definitely some simplifications possible and required).

Some things/questions/observations that come to mind:

• The discrimator field for oneof values can be nilable (in generated code), even for required fields
• Enums in one of fields are currently broken, the actual implementation. This was surfaced by sorbet, will fix this as a follow up PR
• Optional fields take nilable values but then set the default value (which does not get encoded), this was also surfaced by sorbet

[tenderlove]

"required" and "optional" refer to the encoding. If a field is "required", it means that it will always be encoded. If it's "optional", then it's only encoded if it is not the default value. (This is confusing from a user's perspective, but unfortunately that's how the spec is defined)

I think only fields that contain submessages are actually nillable. Everything else should require some kind of value.

[TobiasBales]

"required" and "optional" refer to the encoding. If a field is "required", it means that it will always be encoded. If it's "optional", then it's only encoded if it is not the default value. (This is confusing from a user's perspective, but unfortunately that's how the spec is defined)

I think only fields that contain submessages are actually nillable. Everything else should require some kind of value.

Interesting.
So should the constructor not accept nil values but rather have a default value then?
And setters (for optional fields) would then also just accept the non nilable type?
Doing that would simplify some things indeed

[nirvdrum]

@TobiasBales Is this PR something you're still interested in? I accidentally overlooked it when we resumed development on Protoboeuf. There are a few conflicts, but they might be easy to resolve. Did you happen to make any progress with Aaron's feedback? If we're going to merge this, doing so soon would be best before ongoing development causes the branch to fall more out of date.