test: verify synthetic fields are skipped

[coryan]

Synthetic fields need to be skipped during serialization. We had no
explicit tests for this functionality.

Motivated by #2376

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.57%. Comparing base (56d472f) to head (7833ad8).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2393   +/-   ##
=======================================
  Coverage   95.57%   95.57%           
=======================================
  Files          75       75           
  Lines        2940     2940           
=======================================
  Hits         2810     2810           
  Misses        130      130           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dbolduc]

Food for thought, but nothing blocking this PR.

It sort of affects my current work which involves building the paths.

FTR, my plan is to keep taking references to fields used in the path and copying them into the path. I am not gonna block on this.

[dbolduc]

I am late to the party and confused. I read:

google-cloud-rust/generator/internal/api/model.go

Lines 505 to 508 in 56d472f

	// The OpenAPI specifications have incomplete `*Request` messages. We inject
	// some helper fields. These need to be marked so they can be excluded
	// from serialized messages and in other places.
	Synthetic bool

So these synthetic fields are part of the path we would use to make the RPC, not part the request? That makes sense. But don't things work the same way with gRPC transcoding?

Hmm, I thought fields in the path need not be repeated in the body (even when the body is *). But I don't see that stated in https://google.aip.dev/127.

[dbolduc]

Ah, 2.4.2 in go/actools-regapic-grpc-transcoding says fields from the path should not be included in the body, but this is optional. So what we are doing is fine.

Still the way this is unified feels weird to me. Seems like we could serialize the fields, even if they are synthetic. But then in the transport.rs layer, we could std::mem::take the fields out of the request for use in the path.

Thoughts?