[wiki migration] Infra team pages (#148718)

This sorts the wiki pages owned by the Infra team in the docs/ directory as planned in [flutter.dev/go/migrate-flutter-wiki-spreadsheet](https://docs.google.com/spreadsheets/d/1x65189ZBdNiLRygpUYoU08pwvXD4M-Z157c6pm8deGI/edit?usp=sharing) 

It also adds the team-infra label to the bot for future PRs.

Image assets were checked in here: flutter/assets-for-api-docs#246

Changes to the content were only updating links. The remaining wiki links will be updated after the rest of the pages are relocated, the original wiki links still work in the meantime.

Part of flutter/flutter#145009

Author: Piinks

.github/labeler.yml

@@ -157,6 +157,11 @@ team-engine:
     - any-glob-to-any-file:
       - docs/engine/**/*
 
+team-infra:
+  - changed-files:
+    - any-glob-to-any-file:
+      - docs/infra/**/*
+
 team-release:
   - changed-files:
     - any-glob-to-any-file:

docs/unsorted_wiki/Labeling-PRs.md renamed to docs/contributing/Labeling-PRs.md

@@ -1,19 +1,19 @@
-Further documentation on Flutter's build infrastructure can be found in <https://github.com/flutter/flutter/blob/master/dev/bots/README.md>.
+Further documentation on Flutter's build infrastructure can be found in <https://github.com/flutter/flutter/blob/main/dev/bots/README.md>.
 
 ## Requirements for a Flutter/LUCI build
 
 A general outline of the requirements that a Flutter CI test shard has:
 
 1. On LUCI, test shards map to builders. Each test shard must have its own LUCI builder. For the Framework, these are defined in [framework_config.star](https://flutter.googlesource.com/infra/+/refs/heads/main/config/framework_config.star). Generally you will need to have both a pre-submit ("try" in LUCI terminology) builder and a post-submit ("prod") builder.
-1. This LUCI builder will specify a "recipe" to run. These are [starlark](https://github.com/bazelbuild/starlark) scripts that determine the actual CI steps to run, and are defined in [flutter.googlesource.com/recipes](https://flutter.googlesource.com/recipes). Most Framework tests use the [flutter/flutter_drone.py](https://flutter.googlesource.com/recipes/+/refs/heads/master/recipes/flutter/flutter_drone.py) recipe. To learn how to edit these, see <https://github.com/flutter/flutter/blob/master/dev/bots/README.md#editing-a-recipe>.
-1. Builders are then added to [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml). These files are read by [Flutter's build dashboard](https://flutter-dashboard.appspot.com/#/build), and are used for scheduling builds.
+1. This LUCI builder will specify a "recipe" to run. These are [starlark](https://github.com/bazelbuild/starlark) scripts that determine the actual CI steps to run, and are defined in [flutter.googlesource.com/recipes](https://flutter.googlesource.com/recipes). Most Framework tests use the [flutter/flutter_drone.py](https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/flutter/flutter_drone.py) recipe. To learn how to edit these, see <https://github.com/flutter/flutter/blob/main/dev/bots/README.md#editing-a-recipe>.
+1. Builders are then added to [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml). These files are read by [Flutter's build dashboard](https://flutter-dashboard.appspot.com/#/build), and are used for scheduling builds.
 
 ## Steps to add a new Framework Test Shard
 
 It is important to land these changes in order to prevent any failing builds during the migration period:
 
-1. Framework tests are run by a Dart test runner called [test.dart](https://github.com/flutter/flutter/blob/master/dev/bots/test.dart) that lives in the framework repository. Any new test shards must first be added to this file. Merge this framework change. Note that sharding an existing test doesn't need to update test.dart.
-1. Update [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml) in the Framework tree to include the newly added builder following [CI_YAML.md](https://github.com/flutter/cocoon/blob/main/CI_YAML.md#adding-new-targets). Ensure that the "shard" and "subshard"/"subshards" properties match what was added to test.dart in the previous step. Verify that the entry is marked as `bringup: true`. New shards should always be marked in bringup to verify they are passing on master before being able to block the tree. Merge this change. Note that the new shard will not run in presubmit at this point as the target is with `bringup: true`.
+1. Framework tests are run by a Dart test runner called [test.dart](https://github.com/flutter/flutter/blob/main/dev/bots/test.dart) that lives in the framework repository. Any new test shards must first be added to this file. Merge this framework change. Note that sharding an existing test doesn't need to update test.dart.
+1. Update [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml) in the Framework tree to include the newly added builder following [CI_YAML.md](https://github.com/flutter/cocoon/blob/main/CI_YAML.md#adding-new-targets). Ensure that the "shard" and "subshard"/"subshards" properties match what was added to test.dart in the previous step. Verify that the entry is marked as `bringup: true`. New shards should always be marked in bringup to verify they are passing on master before being able to block the tree. Merge this change. Note that the new shard will not run in presubmit at this point as the target is with `bringup: true`.
 1. Monitor the CI results of the new shard on the [Flutter build dashboard](https://flutter-dashboard.appspot.com/#/build). After 50 consecutive passing builds without any flakes, the flake bot will create a PR to remove the `bringup: true` parameter from `.ci.yaml` in the Framework tree. This will allow the test to block the tree, preventing breakages. With this change, the new shard will start running in presubmit automatically, unless specify `presubmit: false`. Note the flake bot runs once a week on Weds.
 
 Note: if a new post-submit target is renamed from an existing target, there is no need to follow the bringup process.

docs/unsorted_wiki/Adding-a-new-Test-Shard.md renamed to docs/infra/Adding-a-new-Test-Shard.md

@@ -20,15 +20,15 @@ The rollers work by updating a [CIPD](https://chrome-infra-packages.appspot.com/
 
 We use an auto-roller for Skia rolls. It's status can be viewed at <https://skia-flutter-roll.skia.org/>. In case of  build failures or other errors, ping the Flutter-Skia chat channel. In case you get no response, you can login with an @google.com account and pause the roller (or ask someone with an @google.com account to do so). Please specify a descriptive reason and file a bug to re-enable the rollers as soon as possible.
 
-The bot updates the `skia_revision` line of <https://github.com/flutter/engine/blob/master/DEPS>.
+The bot updates the `skia_revision` line of <https://github.com/flutter/engine/blob/main/DEPS>.
 
 Skia also uses an auto-roller for Fuchsia; see <https://autoroll-internal.skia.org/r/fuchsia-autoroll>.
 
 ## Engine to Framework
 
 The engine is automatically rolled to the framework. It is configured by <https://skia.googlesource.com/skia-autoroll-internal-config.git/+/main/skia-infra-public/flutter-engine-flutter.cfg>.
 
-The bot updates <https://github.com/flutter/flutter/blob/master/bin/internal/engine.version> to point to the latest revision of the engine *whose artifacts built successfully*, as determined by looking at the [Engine Console](https://ci.chromium.org/p/flutter/g/engine/console).
+The bot updates <https://github.com/flutter/flutter/blob/main/bin/internal/engine.version> to point to the latest revision of the engine *whose artifacts built successfully*, as determined by looking at the [Engine Console](https://ci.chromium.org/p/flutter/g/engine/console).
 
 
 ### Making a breaking change
@@ -41,15 +41,15 @@ To roll the engine manually in the case you have a breaking change exemption, yo
 
 When you change the `engine.version` file locally, you should delete `$FLUTTER_ROOT/bin/cache` and then run `flutter precache` to ensure that all your local artifacts and snapshots are updated. You can then run tests and be sure that they are running against the latest version of the assets you need.
 
-You may find it helpful to use the [`$ENGINE_ROOT/src/flutter/tools/engine_roll_pr_desc.sh`](https://github.com/flutter/engine/blob/master/tools/engine_roll_pr_desc.sh) to create a PR description. Doing this helps us track down what commits have rolled in more quickly, and properly link to other commits and pull requests for commenting and tracking.
+You may find it helpful to use the [`$ENGINE_ROOT/src/flutter/tools/engine_roll_pr_desc.sh`](https://github.com/flutter/engine/blob/main/tools/engine_roll_pr_desc.sh) to create a PR description. Doing this helps us track down what commits have rolled in more quickly, and properly link to other commits and pull requests for commenting and tracking.
 
 For example, to generate a description from hash deadbeef to beefdead:
 
 ```bash
 $ ./tools/engine_roll_pr_desc.sh deadbeef..beefdead
 ```
 
-_See also: [[Debugging the engine]], which includes instructions on bisecting a roll failure._
+_See also: [Debugging the engine](https://github.com/flutter/flutter/wiki/Debugging-the-engine), which includes instructions on bisecting a roll failure._
 
 
 ## Dart to Engine
@@ -61,6 +61,6 @@ If there are any issues with this process or the autoroller dashboard, contact b
 ## Flutter Pub Roller
 
 The bot account [flutter-pub-roller-bot](https://github.com/flutter-pub-roller-bot) runs the script at
-https://github.com/flutter/flutter/blob/master/dev/conductor/bin/packages_autoroller on post-submit of
+https://github.com/flutter/flutter/blob/main/dev/conductor/bin/packages_autoroller on post-submit of
 every framework commit to keep the pub dependencies in the [framework](https://github.com/flutter/flutter)
 up to date.

docs/unsorted_wiki/Autorollers.md renamed to docs/infra/Autorollers.md

@@ -5,13 +5,13 @@ Flutter FirebaseLab tests are used to build flutter applications and to run them
 These tests consist of two parts:
 
 *   [Firebaselab recipe](https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/firebaselab/firebaselab.py)
-*   [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml#L413) configuration file
+*   [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml#L413) configuration file
 
 The recipe supports three properties: **physical\_devices** to specify actual hardware connected to firebase infra to run tests, **virtual\_devices** to specify the virtual devices(avd) to use and **task\_name** for selecting the integration test to build.
 
 physical\_device and virtual\_device are strings that take the **MODEL\_ID** format defined by firebase. Use `gcloud firebase test android models list` (assuming you have [gcloud](https://cloud.google.com/sdk/gcloud) installed) for a list of possible model id’s.
 
-Task name is the subdirectory of [dev/integration\_tests](https://github.com/flutter/flutter/tree/master/dev/integration_tests) (e.g. android\_views, channels, etc ) that contains the integration test to build.
+Task name is the subdirectory of [dev/integration\_tests](https://github.com/flutter/flutter/tree/main/dev/integration_tests) (e.g. android\_views, channels, etc ) that contains the integration test to build.
 
 The following is an example of the properties format:
 
@@ -51,9 +51,9 @@ This is only required for manually running the steps
 
 ## Adding a Firebaselab Test
 
-*   Step 1: Select the integration test to use from [dev/integration\_tests](https://github.com/flutter/flutter/tree/master/dev/integration_tests)
+*   Step 1: Select the integration test to use from [dev/integration\_tests](https://github.com/flutter/flutter/tree/main/dev/integration_tests)
 *   Step 2: Select the physical and virtual devices to run the test on. You can use `gcloud firebase test android models list` and `gcloud firebase test ios models list` to find the available devices.
-*   Step 3: Write a .ci.yaml target configuration in the [flutter/flutter .ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml) file providing the task\_name, virtual\_devices, physical\_devices and recipe properties.
+*   Step 3: Write a .ci.yaml target configuration in the [flutter/flutter .ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml) file providing the task\_name, virtual\_devices, physical\_devices and recipe properties.
 *   Step 4: Create a PR with the new target. The presubmit checks will run basic validations on yaml format.
 *   Step 5: Wait for the change to propagate.
 *   Step 6: Fix any potential issues and remove `bringup: true` to validate the changes end to end in presubmit.