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]

What is the intention to set "total count" to 0 here instead of 1, and omit increment one in count-router-inner-conditions?

[yoshisatoyanagisawa]

I guess setting |maxCount| is to use the same value not only in check-router-registration-limit, but also in count-router-inner-conditions.
However, do we need to ask the browser implementor to implement the early return?

[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.