refactor(frontend): rename streaming_rate_limit to backfill_rate_limit for mv backfilling and source_rate_limit for source updates

[kwannoel]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Closes #16466

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

After this PR we refactor streaming_rate_limit into:

• source_rate_limit. This will be applied to TABLE WITH SOURCE, TABLE.
• backfill_rate_limit. This will be applied to MV, SINK, INDEX for their backfill.

[stdrc]

IMO the difference between streaming_rate_limit and backfill_rate_limit can be very confusing after this...I propose another approach:

streaming_rate_limit -- still have the same meaning as before, controls both backfill and source/upstream
streaming_backfill_rate_limit -- only controls backfill
streaming_source_rate_limit -- only controls source/upstream

Is this doable?

[kwannoel]

IMO the difference between streaming_rate_limit and backfill_rate_limit can be very confusing after this...I propose another approach:

streaming_rate_limit -- still have the same meaning as before, controls both backfill and source/upstream
streaming_backfill_rate_limit -- only controls backfill
streaming_source_rate_limit -- only controls source/upstream

Is this doable?

Seems more complex to have 3 variables to control it, both in terms of ux and our own maintenance.

This LGTM:

> streaming_backfill_rate_limit -- only controls backfill
> streaming_source_rate_limit -- only controls source/upstream

[kwannoel]

Pause this PR for a while for some prereq work. See #17796 (comment)

[stdrc]

IMO the difference between streaming_rate_limit and backfill_rate_limit can be very confusing after this...I propose another approach:

streaming_rate_limit -- still have the same meaning as before, controls both backfill and source/upstream
streaming_backfill_rate_limit -- only controls backfill
streaming_source_rate_limit -- only controls source/upstream

Is this doable?

Seems more complex to have 3 variables to control it, both in terms of ux and our own maintenance.

This LGTM:

> streaming_backfill_rate_limit -- only controls backfill
> streaming_source_rate_limit -- only controls source/upstream

I was suggesting to keep it for backward-compatibility purpose, as a fallback value of the following two. Either keeping it or removing it looks good to me actually.

[kwannoel]

Done further refactoring as per @stdrc's suggestion. Renamed streaming_rate_limit to source_rate_limit to be more precise, and remove any ambiguity.

This PR will introduce a breaking change, and I have included the details in the PR description.

[stdrc]

LGTM

[lmatz]

it seems searching backfill_rate_limit in the documentation produce no results, is it documented before?

[stdrc]

it seems searching backfill_rate_limit in the documentation produce no results, is it documented before?

It's added in this PR.

[kwannoel]

it seems searching backfill_rate_limit in the documentation produce no results, is it documented before?

We just make streaming_rate_limit more fine-grained. Instead of setting all kinds of rate limit via streaming_rate_limit, we use backfill_rate_limit, source_rate_limit to set the different types of rate limit.