Add docs for dealing with resource_sizes perf alerts

tools/perf/docs/perf_regression_sheriffing.md

 # Perf Regression Sheriffing (go/perfregression-sheriff)
 
 The perf regression sheriff tracks performance regressions in Chrome's
 continuous integration tests. Note that a [new rotation](perf_bot_sheriffing.md)
 has been created to ensure the builds and tests stay green, so the perf
 regression sheriff role is now entirely focused on performance.
 
 **[Rotation calendar](https://calendar.google.com/calendar/embed?src=google.com_2fpmo740pd1unrui9d7cgpbg2k%40group.calendar.google.com)**
 
 ## Key Responsibilities
@@ skipping 22 matching lines @@
 
 The list can be sorted by clicking on the column header. When you click on the
 checkbox next to an alert, all the other alerts that occurred in the same
 revision range will be highlighted.
 
 Check the boxes next to the alerts you want to take a look at, and click the
 "Graph" button. You'll be taken to a page with a table at the top listing all
 the alerts that have an overlapping revision range with the one you chose, and
 below it the dashboard shows graphs of all the alerts checked in that table.
 
-1. **Look at the graph**.
+1. **For alerts related to `resource_sizes`:**
+    * Refer to [apk_size_regressions.md](apk_size_regressions.md).
+2. **Look at the graph**.
     * If the alert appears to be **within the noise**, click on the red
       exclamation point icon for it in the graph and hit the "Report Invalid
       Alert" button.
     * If the alert appears to be **reverting a recent improvement**, click on
       the red exclamation point icon for it in the graph and hit the "Ignore
       Valid Alert" button.
     * If the alert is **visibly to the left or the right of the
       actual regression**, click on it and use the "nudge" menu to move it into
       place.
     * If there is a line labeled "ref" on the graph, that is the reference build.
       It's an older version of Chrome, used to help us sort out whether a change
       to the bot or test might have caused the graph to jump, rather than a real
       performance regression. If **the ref build moved at the same time as the
       alert**, click on the alert and hit the "Report Invalid Alert" button.
-2. **Look at the other alerts** in the table to see if any should be grouped together.
+3. **Look at the other alerts** in the table to see if any should be grouped together.
    Note that the bisect will automatically dupe bugs if it finds they have the
    same culprit, so you don't need to be too aggressive about grouping alerts
    that might not be related. Some signs alerts should be grouped together:
     * If they're all in the same test suite
     * If they all regressed the same metric (a lot of commonality in the Test
       column)
-3. **Triage the group of alerts**. Check all the alerts you believe are related,
+4. **Triage the group of alerts**. Check all the alerts you believe are related,
   and press the triage button.
     * If one of the alerts already has a bug id, click "existing bug" and use
       that bug id.
     * Otherwise click "new bug". Be sure to cc the
       [test owner](http://go/perf-owners) on the bug.
-4. **Look at the revision range** for the regression. You can see it in the
+5. **Look at the revision range** for the regression. You can see it in the
    tooltip on the graph. If you see any likely culprits, cc the authors on the
    bug.
-5. **Optionally, kick off more bisects**. The perf dashboard will automatically
+6. **Optionally, kick off more bisects**. The perf dashboard will automatically
    kick off a bisect for each bug you file. But if you think the regression is
    much clearer on one platform, or a specific page of a page set, or you want
    to see a broader revision range feel free to click on the alert on that graph
    and kick off a bisect for it. There should be capacity to kick off as many
    bisects as you feel are necessary to investigate; [give feedback](#feedback)
    below if you feel that is not the case.
 
 ## Triaging Data Stoppage Alerts
 
 Data stoppage alerts are listed on the
@@ skipping 78 matching lines @@
   [go/bad-bisects](https://docs.google.com/spreadsheets/d/13PYIlRGE8eZzsrSocA3SR2LEHdzc8n9ORUoOE2vtO6I/edit#gid=0).
   The team triages these regularly. If you spot a really clear bug (bisect
   job red, bugs not being updated with bisect results) please file it in
   crbug with component `Tests>AutoBisect`. If a bisect problem is blocking a
   perf regression bug triage, **please file a new bug with component
   `Tests>AutoBisect` and block the regression bug on the bisect bug**. This
   makes it much easier for the team to triage, dupe, and close bugs on the
   infrastructure without affecting the state of the perf regression bugs.
 * **Noisy Tests**: Please file a bug in crbug with component `Tests>Telemetry`
   and [cc the owner](http://go/perf-owners).