Add limits to the number of router rule registration

[sisidovski]

In #1746, we discussed if the spec should give guidelines about the limit of added routes, and how the user agent should behave if the added routes exceeds the limit.

We have an agreement that we're willing to pick some specific limits. This PR proposes 1024 as the total number of router conditions, and 10 as the max depth of router condition nesting level. If it exceeds those limits, the user agent throws a TypeError.

For the counting conditions part, let me clarify how we calculate the total count as this a bit tricky.

Assuming that router conditions can be nested by using or and not syntaxes. We count every sub router conditions inside the parent or or not condition, including the parent condition itself.

Here are some examples.

self.addEventListener('install', event => {
  // The condition count of this addRoutes() is 1.
  //
  // The max nesting level is 1.
  event.addRoutes({
    condition: {
      urlPattern: { pathname: "/form/*" },
    },
    source: "network"
  });

  // The condition count of this addRoutes() is 1.
  // Even though there are multiple fields in one router condition, we treat is as 1.
  //
  // The max nesting level is 1.
  event.addRoutes({
    condition: {
      urlPattern: { pathname: "/form/*" },
      requestMethod: "post",
      requestMode: "navigation",
      runningStatus: "running"
    },
    source: "network"
  });

  // The condition count of this addRoutes() is 2.
  //
  // The max nesting level is 1.
  event.addRoutes([
    {
      condition: { requestMethod: "post" },
      source: "network"
    },
    {
      condition: { requestMethod: "get" },
      source: "network"
    }
  ]);

  // The condition count of this addRoutes() is 4.
  // `or` condition itself is inluded in the total count.
  //
  // The max nesting level is 2.
  event.addRoutes([
    {
      condition: {
        or: [
          { urlPattern: { pathname: "/form/*" } },
          { requestMethod: "post" },
          { requestMode: "navigate" },
        ]
      },
      source: "network"
    }
  ]);

  // The condition count of this addRoutes() is 7.
  // 3 `or` + 1 `not` + 1 `requestMethod` + 1 `requestMode` + 1 `runningStatus` = 7
  //
  // The max nesting level is 5.
  event.addRoutes([
    {
      condition: {
        or: [
          {
            or: [{
              or: [
                { requestMethod: 'get' },
                {
                  not: {
                    requestMode: 'navigate'
                  }
                }
              ]
            }]
          },
          { runningStatus: 'running' }
        ]
      },
      source: "network"
    }
  ]);

  // In total, 15 router conditions are registered in the install event.
  // Max nesting level is 5.
});

#1714 will be migrated into this PR.

---

Preview | Diff

[yoshisatoyanagisawa]

I feel that the number of conditions under |orCondition| may not be counted?
e.g.
or: [{singleRule}, {singleRule}, {singleRule}]
|result| might be overwritten by the result for {singleRule} for three times, but we want |result|'s [=total count=] to be three.

[sisidovski]

I believe those are correctly counted? Let's walk through the current algorithm. btw, under the current design, or: [{singleRule}, {singleRule}, {singleRule}], this total count is expected to be four (or should be counted as one condition).

1. We call count-router-inner-conditions with the root or condition. The total count will be one.
2. Starts the for loop with the first {singleRule}.
3. In the first sub-step, |result|'s total count will be two, because we pass "one" as total count to count-router-inner-conditions in this sub-step. total count will be incremented inside the algorithm.
4. The second {singleRule} is handled. total count will be three.
5. The third {singleRule} is handled. total count will be four.

Am I missing something?

[yoshisatoyanagisawa]

Upon the sync, I understand how this works.
The last result will be the |currentResult|'s total count, and it will be passed to the coming count-router-inner-conditions. Therefore, the value will be updated like:

1. |currentResult| is passed to count-router-inner-conditions's argument
2. in the count-router-inner-conditions, the given argument will be updated
3. the updated value will be returned
4. |currentResult|'s total count will be set to the returned result's total count.

Therefore, even if the algorithm does not have add x + y like operation, the count will be updated.
I feel the data flow is difficult to track at once, and hope some notes to explain that as you have already noted below.

[sisidovski]

I've updated to set |result| to be the result of count-router-inner-conditions directly, and now we don't have to set total count explicitly. Hence note is not required anymore. WDYT?

[yoshisatoyanagisawa]

Maybe?
After reviewing this, I got familiar with the algorithm well and can easily read this like so.
However, I am not sure how people first look feel on this. Let me delegate the decision to other reviewers on this.

[domenic]

The algorithm seems pretty intuitive to me now without needing a note. It is clear that result is mutated and the for-loop over all _or conditions means it will be mutated once for each sub-condition.

[yoshisatoyanagisawa]

Sorry for the recent update, but will you resolve the conflicts?

[sisidovski]

Sorry for the recent update, but will you resolve the conflicts?

Done

[yoshisatoyanagisawa]

Thank you. lgtm.

[yoshisatoyanagisawa]

@youennf @asutherland @domenic Will you take a look at the PR?

[yoshisatoyanagisawa]

Let me wait for a few days to gather thoughts from who joined #1746 before merge.

[domenic]

The algorithm seems pretty intuitive to me now without needing a note. It is clear that result is mutated and the for-loop over all _or conditions means it will be mutated once for each sub-condition.

[asutherland]

Thank you!