fix(hc): Replace RPC methods with tuples as return types

[RyanSkonnord]

The ultimate goal here is to replace all RPC methods that have a fixed-length tuple as a return type. The motive is to be able to represent those return types in an OpenAPI schema, for consumption by tools that will automatically detect breaking changes. Although constant-size tuples are supported under Pydantic for purposes of serialization, OpenAPI does not let us represent a logical type by constraining an array length (nor to specify a type at each array index).

These return type changes are breaking on production. (See prior discussion at #67027. Thanks @markstory.) This PR (which I intend to leave in draft status indefinitely) contains the five steps that we must take in order to avoid any production errors, assuming that each step is fully rolled out before the next starts. Those steps are represented in the first five commits in the branch (plus any fixups that I might have added by the time you read this).

I plan to make a one new PR at a time for each of those steps. I invite review of the entire plan on this PR.

1. 084e973
2. 66536fe
3. c7d0eaf
4. 3015cd0
5. 7b758e4

[RyanSkonnord]

PR for Step 1: #67321

[RyanSkonnord]

We can avoid changing the return type by making it no longer an @rpc_method. That's a good way to go, because otherwise we would have to add yet another single-case model class.

However, removing the @rpc_method decorator is as much a breaking change as changing the return type, because it will no longer respond to requests from concurrently-running clients. So, it gets the same swapping procedure as the other methods.

[codecov]

Codecov Report

Attention: Patch coverage is 95.23810% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 84.33%. Comparing base (fbbabdb) to head (7b758e4).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #67320      +/-   ##
==========================================
- Coverage   84.33%   84.33%   -0.01%     
==========================================
  Files        5309     5309              
  Lines      237230   237249      +19     
  Branches    41029    41026       -3     
==========================================
+ Hits       200073   200082       +9     
- Misses      36939    36949      +10     
  Partials      218      218              

Files	Coverage Δ
src/sentry/api/serializers/models/group.py	95.84% <100.00%> (+<0.01%)	⬆️
src/sentry/integrations/github/webhook.py	80.89% <100.00%> (ø)
src/sentry/integrations/gitlab/webhooks.py	89.72% <100.00%> (ø)
src/sentry/integrations/jira/utils/api.py	90.76% <100.00%> (ø)
src/sentry/integrations/mixins/repositories.py	91.04% <100.00%> (ø)
src/sentry/integrations/slack/webhooks/action.py	90.55% <100.00%> (ø)
src/sentry/integrations/utils/scope.py	86.95% <100.00%> (ø)
...c/sentry/services/hybrid_cloud/integration/impl.py	87.61% <100.00%> (ø)
.../sentry/services/hybrid_cloud/integration/model.py	90.00% <100.00%> (+0.52%)	⬆️
...sentry/services/hybrid_cloud/notifications/impl.py	96.92% <100.00%> (+0.04%)	⬆️
... and 8 more

... and 4 files with indirect coverage changes

[RyanSkonnord]

I've discovered four more methods that will need breaking changes.

• OrganizationMappingService.upsert
• ControlOrganizationProvisioningRpcService.bulk_create_organization_slug_reservations
• ImportExportService.export_by_model
• ImportExportService.import_by_model

I'm thinking I'll try to roll them into this set of changes before proceeding.

[RyanSkonnord]

Replaced by #68345