feat(api): Allow per-org rate limit overrides for project transfer

[cleptric]

The ProjectTransferEndpoint POST rate limit was a hardcoded 3/hour per
user. Some orgs legitimately need a higher ceiling (e.g. during a bulk
project migration) and bumping the value previously required a code
deploy.

The callable form is required because the rate-limit middleware reads
view_cls.rate_limits once per class import for static configs — only a
callable is re-evaluated per request, which is necessary for the option
to actually take effect at runtime.

[github-actions]

Backend Test Failures

Failures on 5a545fc in this run:

tests/snuba/tagstore/test_tagstore_backend.py::TagStorageTest::test_get_group_tag_keys_and_top_values_generic_issue — log

[gw0] linux -- Python 3.13.1 /home/runner/work/sentry/sentry/.venv/bin/python3
tests/snuba/tagstore/test_tagstore_backend.py:305: in test_get_group_tag_keys_and_top_values_generic_issue
    assert set(tags) == {"foo", "biz", "environment", "sentry:user", "level", "sentry:release"}
E   AssertionError: assert set() == {'biz', 'envi...'sentry:user'}
E     
E     Extra items in the right set:
E     'level'
E     'environment'
E     'sentry:user'
E     'foo'
E     'sentry:release'
E     'biz'
E     
E     Full diff:
E     + set()
E     - {
E     -     'biz',
E     -     'environment',
E     -     'foo',
E     -     'level',
E     -     'sentry:release',
E     -     'sentry:user',
E     - }

tests/snuba/tagstore/test_tagstore_backend.py::TagStorageTest::test_get_group_tag_value_count_generic — log

[gw1] linux -- Python 3.13.1 /home/runner/work/sentry/sentry/.venv/bin/python3
tests/snuba/tagstore/test_tagstore_backend.py:410: in test_get_group_tag_value_count_generic
    assert (
E   AssertionError: assert 0 == 1
E    +  where 0 = <bound method SnubaTagStorage.get_group_tag_value_count of <sentry.tagstore.snuba.backend.SnubaTagStorage object at 0x7f735cf6b520>>(<Group at 0x7f7376785e50: id=232, project_id=4558003108446240>, 179, 'foo', {'organization_id': 1234, 'referrer': 'tagstore.get_group_tag_value_count'})
E    +    where <bound method SnubaTagStorage.get_group_tag_value_count of <sentry.tagstore.snuba.backend.SnubaTagStorage object at 0x7f735cf6b520>> = <sentry.tagstore.snuba.backend.SnubaTagStorage object at 0x7f735cf6b520>.get_group_tag_value_count
E    +      where <sentry.tagstore.snuba.backend.SnubaTagStorage object at 0x7f735cf6b520> = <tests.snuba.tagstore.test_tagstore_backend.TagStorageTest testMethod=test_get_group_tag_value_count_generic>.ts
E    +    and   179 = <Environment at 0x7f73786180d0: id=179, organization_id=4558003108380704, name='test'>.id

tests/snuba/tagstore/test_tagstore_backend.py::TagStorageTest::test_get_group_tag_key_generic — log

[gw1] linux -- Python 3.13.1 /home/runner/work/sentry/sentry/.venv/bin/python3
tests/snuba/tagstore/test_tagstore_backend.py:564: in test_get_group_tag_key_generic
    assert (
src/sentry/tagstore/snuba/backend.py:808: in get_group_tag_key
    return self.__get_tag_key_and_top_values(
src/sentry/tagstore/snuba/backend.py:429: in __get_tag_key_and_top_values
    raise TagKeyNotFound if group is None else GroupTagKeyNotFound
E   sentry.tagstore.exceptions.GroupTagKeyNotFound

tests/snuba/tagstore/test_tagstore_backend.py::TagStorageTest::test_get_top_group_tag_values_generic — log

[gw1] linux -- Python 3.13.1 /home/runner/work/sentry/sentry/.venv/bin/python3
tests/snuba/tagstore/test_tagstore_backend.py:377: in test_get_top_group_tag_values_generic
    resp = self.ts.get_top_group_tag_values(
src/sentry/tagstore/snuba/backend.py:1194: in get_top_group_tag_values
    tag = self.__get_tag_key_and_top_values(
src/sentry/tagstore/snuba/backend.py:429: in __get_tag_key_and_top_values
    raise TagKeyNotFound if group is None else GroupTagKeyNotFound
E   sentry.tagstore.exceptions.GroupTagKeyNotFound

[wedamija]

I'd probably recommend putting some kind of reasonable upper limit on this. In the past, when we allow increased limits we've usually just made it a feature flag with a hard coded higher rate limit/quota/whatever.

So we can either take that approach here, or cap it to some amount per hour.

I'd probably remove the ability to change the window, and just allow the limit to be modified. Just easier to reason about if we know that it's an hourly rate-limit and we allow you to increase it from 3 up to (say) 50

[vgrozdanic]

I took it over from Michi, moved it to only a limit with a fixed window, we can set the limit to something reasonable in settings (e.g. 20 per hour) to help the user with migration, and bring it back down until there is a need again for it

[github-actions]

Backend Test Failures

Failures on af81eb5 in this run:

tests/sentry/core/endpoints/test_project_transfer.py::ProjectTransferTest::test_rate_limit — log

[gw0] linux -- Python 3.13.1 /home/runner/work/sentry/sentry/.venv/bin/python3
tests/sentry/core/endpoints/test_project_transfer.py:106: in test_rate_limit
    assert response.status_code == 429
E   assert 404 == 429
E    +  where 404 = <Response status_code=404, "application/json">.status_code