chore(api, shared, app-generic): Convert API rate limit FF to be LaunchDarkly compatible

[rifont]

What change does this PR introduce?

• Convert API rate limit flag from system-critical to feature-flag
• Rename IS_REQUEST_RATE_LIMITING_ENABLED -> IS_API_RATE_LIMITING_ENABLED for naming consistency with features under implementation

Why was this change needed?

• The feature flag was not compatible with LaunchDarkly and could not be resolved at runtime. This change enables rate limiting to be rolled out gradually through strategies such as A/B.

Other information (Screenshots)

N/A

[linear]

NV-3061 🏎️ Rate Limiting NestJS Guard

What?

Create the NestJS guard which is attached to the global App, Controllers and implements the TokenBucketRateLimit use case from NV-3060

• add attachment capability for Methods
• add rate limiting for IP addresses
• add rate limiting headers to responses

Why? (Context

NestJS guards provide a capability to block traffic from the services it protects. We need to be able to protect specific resources from high traffic to enable service resiliency and reliability.

Definition of Done

• Unit test on mock endpoints for both single & multiple resource category by injecting a mock in-memory Redis implementation. Verify that a correct rate limit indicator is returned for each case
• E2E test on mock endpoints for single/multiple resource category
• Rate limit headers present on all responses

[rifont]

"API Rate Limiting" aligns naming with the use-cases under development. If we decide to add Web Socket rate limiting or other types, we can then toggle these features independently.

[rifont]

This file was also renamed from get-is-request-rate-limiting-enabled -> get-is-api-rate-limiting-enabled

[LetItRock]

looks good to me 🎉