always build devtools from a specified, specific sdk version

[devoncarew]

always build devtools from a specified, specific sdk version:

• rev the version of flutter we use to the latest dev release (2.4.0-4.1.pre)
• in the build_release.sh script, validate that we're building with the version specified in flutter-version.txt
• add a new tool/update_flutter_sdk.sh script that can 1) clone the flutter sdk if it doesn't exist, or 2) switch the vended flutter sdk to be the version specified in flutter-version.txt. Developers can just run tool/update_flutter_sdk.sh whenever sdk version changes in order to make sure they're on the correct sdk

Some changes here are a bit proscriptive, and will affect the workflows of people working on this repo, so comments welcome. cc @kenzieschmoll @jacob314 @terrylucas @DanTup

[devoncarew]

I may also need to update this line as well: https://github.com/flutter/devtools/blob/master/.github/workflows/build.yaml#L14.

[DanTup]

I may also need to update this line as well: https://github.com/flutter/devtools/blob/master/.github/workflows/build.yaml#L14

I suspect you can delete that, as it looks like the one being set in the environment is coming from the matrix:

        env:
          BOT: main
          CHANNEL: ${{ matrix.channel }}

If there are other jobs relying on the env variable that don't explicitly have the above, it could be added. That would save having the version in an additional place.

The changes lgtm, but doesn't some of this code run using the users version of Dart (eg. the server code and resolution of dependencies), so is there still value in having some tests run with things like the stable branch? Eg. with this change, could I easily update the repo so that pub global activate devtools would fail with the current stable version of Dart/Flutter but the bots would all be passing?

(this might not matter if editors migrate away from the server/pub versions to SDK-provided versions, but I'm not sure if that's imminent).

[DanTup]

I suspect you can delete that, as it looks like the one being set in the environment is coming from the matrix

Actually, I realise there are multiple jobs in this file now, and that matrix only applies to main, so maybe it is required.

Although my comments above are probably relevant even without this change, if the existing bots are all only running on dev but users may be activating from stable?

[kenzieschmoll]

instead of failing if we are on the wrong version, can update_flutter_sdk.sh be ran automatically as part of this build release script?

[devoncarew]

We could, but I think it's useful for developers to be aware that they need to be building / running with the same SDK as what we ship with. I.e., prompting them to run tool/update_flutter_sdk.sh is probably a good reminder about how to keep your local version synced.

[devoncarew]

I suspect you can delete that, as it looks like the one being set in the environment is coming from the matrix

Actually, I realise there are multiple jobs in this file now, and that matrix only applies to main, so maybe it is required.

Although my comments above are probably relevant even without this change, if the existing bots are all only running on dev but users may be activating from stable?

I'm mostly concerned with ensuring that we're testing against the same version that we're building for the web front-end - that's the bulk of the tool. It's useful - but less critical - to validate the cli against multiple sdk versions.

In the limit devtools will be in lock-step with a sdk version, so we won't have to guess about what we're running on.

[devoncarew]

I'm going to re-work this PR a bit to make it clearer with tests / builds are using what SDKs.

[DanTup]

(There's a 2.5.0-1.0.pre dev now, not sure if it's worth bumping again before landing?)