refactor(generator): prepare for dynamic query params

[dbolduc]

Part of the work for #14492, #10176

To support repeated fields and arbitrary message nesting, we will need to dynamically add the query parameters. An initializer list cannot handle that complexity.

This PR just refactors the construction of the query parameters (in generated code) to prepare for adding loops and such, e.g.: dbolduc@7874e79

---

This change is 

[codecov]

Codecov Report

Attention: Patch coverage is 97.93814% with 2 lines in your changes missing coverage. Please review.

Project coverage is 93.59%. Comparing base (0f86629) to head (f27570f).
Report is 5 commits behind head on main.

Files	Patch %	Lines
...s/golden/v1/internal/golden_rest_only_rest_stub.cc	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #14596      +/-   ##
==========================================
- Coverage   93.59%   93.59%   -0.01%     
==========================================
  Files        2316     2316              
  Lines      207019   207084      +65     
==========================================
+ Hits       193756   193813      +57     
- Misses      13263    13271       +8     

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

[scotthart]

Reviewed 1 of 123 files at r1.
Reviewable status: 1 of 123 files reviewed, 1 unresolved discussion (waiting on @dbolduc)

---

generator/integration_tests/golden/v1/internal/golden_thing_admin_rest_stub.cc line 73 at r1 (raw file):

  std::thread t{[](
          auto p, auto service, auto request, auto rest_context, auto options) {
      std::vector<std::pair<std::string, std::string>> query_params;

Do we want to emit this code when there are no query parameters?

[dbolduc]

Do we want to emit this code when there are no query parameters?

I do. And the ghost of @devbww would. (He would say: no default parameters for internal functions).

I think it is easier to do the same thing all the time instead of handling an empty vector as a special case.

[scotthart]

Fair enough, but let's remove the call to TrimQueryParameters when there are no parameters. I'm pretty sure the optimizer cannot reason about a function in another TU and will have to always call it.

Reviewable status: 1 of 123 files reviewed, 1 unresolved discussion (waiting on @dbolduc)

[dbolduc]

Fair enough, but let's remove the call to TrimQueryParameters when there are no parameters. I'm pretty sure the optimizer cannot reason about a function in another TU and will have to always call it.

I am not worried about calling a function that returns immediately when compared with the subsequent network call.... but it is easy enough to do, so done.

[scotthart]

Reviewed 1 of 117 files at r2.
Reviewable status: 1 of 123 files reviewed, 1 unresolved discussion (waiting on @dbolduc)