chore(generator): move setup_request_id into compat layer

[hebaalazzeh]

Moves setup_request_id defined in the client template into _compat.py.j2 and the related test cases from test_%service.py.j2 to test_compat.py.j2

Associated / Dependent API Core PR: #17738
Towards: #17883

[gemini-code-assist]

Code Review

This pull request refactors the request ID setup logic in the generated client templates by delegating it to google.api_core.gapic_v1.method_helpers.setup_request_id instead of maintaining an inline implementation. As a result, the redundant unit tests for _setup_request_id have been removed from both the templates and the golden integration tests. There are no review comments, so I have no feedback to provide.

[daniel-sanche]

This implementation makes sense if we plan to bump up the api_core requirement Before merging, we need to:

1. get the changes in feat(api_core): add request-id auto-population logic to gapic_v1 public helpers #17738 released
2. update the setup.py to reference the new api_core version floor
3. regenerate goldens

There's also a chance we will want to keep a fallback implementation to keep supporting old api_core versions

[hebaalazzeh]

To simplify things for myself and the review process I am going to break things down:

• Starting with the compat layer: chore(generator): add compatability layer templates #17886
• I will be making progress towards backfilling the compat layer tracked in: Backfill compatibility functions into _compat.py.j2 #17883
• I will add the conditional logic to check if static code exists separately tracked in: Add conditional logic in _compat.py.j2 to import static code from google-api-core #17884

[ohmayr]

@hebaalazzeh I've added some suggestions for generating these methods conditionally. This'll avoid generating these helper methods in libraries which don't need them.

You can regenerate the goldens and you shouldn't see a diff in any of them except storagebatchoperations which has auto populated fields. PTAL.