HTTP codegen mishandles OneOf when used with ResultType views

[sevein]

Goa HTTP codegen generates inconsistent transport code when a design combines:

• a request body that uses OneOf(...)
• a ResultType that also uses OneOf(...)
• viewed/projected results

In that situation, the generated packages can fail to build because different codegen paths disagree about the effective transport shape.

Observed failures include:

• gen/http/{service}/client/cli.go references missing Validate*RequestBody helpers for OneOf request members
• generated client/server response unions reference branch body types that are not emitted
• viewed response bodies are projected in some places but not others, so generated client decode/init code still refers to fields removed by the selected view

Minimal repros:

• oneof_resulttype_client_bug:
  Client CLI references missing Validate*RequestBody helpers for OneOf request-body members.
• oneof_direct_result_bug:
  Direct ResultType response generates a union whose response branch body types are never emitted.
• oneof_result_projection_bug:
  Projected/viewed responses mix projected and unprojected OneOf shapes, producing stale type references across client/server HTTP codegen.

Note: gpt-5.4-high came up with a fix (sevein@1e5c84e), in case it saves you some time. The fix seems to address the problem seen in the minimal repros above (sevein/examples@180abb3).

[raphael]

Thanks for the excellent repros and for putting together the prototype fix in 1e5c84e. I took the same overall approach and opened #3917.

The core fix is effectively the same as your patch:

• use the effective projected client response body consistently in HTTP codegen when the design fixes a single view
• align OneOf object-branch validation with value-shaped request-body contexts

The main differences in the PR are:

• I named the helper effectiveClientResponseBody because it is not collection-specific
• I added more direct regression coverage around the HTTP OneOf projection path and the validation-context behavior
• on the current tree, the change also makes explicit-view streaming collection clients decode into the projected concrete collection type, so I updated those expectations as part of the fix

So overall: your patch was directionally right and very close to what landed in the PR. Thanks again for doing the hard work of isolating the problem so clearly.

[sevein]

Brilliant, your fixes worked flawlessly! Thank you so much.