Address upgrade friction during product releases

[BillWagner]

I went through our dependabot PRs this morning after releasing .NET 6. The .NET 6 product, and the various NuGet packages have all been upgraded. In this repo, and our other related repos, the upgrade actions created a number of friction points. I'm capturing those here. We have a year to consider how to address them:

• Dependabot doesn't update the TFM: None of our bots submit PRs to update the TFM (from net5.0 to net6.0). As a result, many of the dependabot PRs didn't build. The dependabot PRs would (correctly) update an extension package from 5.x to 6.0. But, those updated extensions required the updated TFM.
• Dependabot creates 1 PR for each project X package combination: On major releases, this is more than 100 PRs. That's painful. We should be able to scope the PRs by folder / area. For instance, one PR for all updates to .NET Fundamentals, one PR for all ML.NET updates, one for all Azure SDK samples, etc.
• Dependabot rebases on each PR merge: This is related to the previous concern. Merging these PRs takes a long time, and uses extensive resources to do all the build actions on each rebase for all currently open Dependabot PRs.
• Rate limits on GitHub resources: Because of the previous point, we ran into some rate limits on PRs for other work.

I can think of a few ways to address these ideas.

• We could update the version sweeper to open PRs for new TFMs. (We've filed dependabot/dependabot-core#1953 with dependabot as well)
• We could build an action to approve + merge existing dependabot PRs.
• We could look for a different dependency manager, or consider creating one. There are a number of ideas / issues for dependabot on this feature.
• Dependabot could address dependabot/dependabot-core#1190

[IEvangelist]

.NET version sweeper

I did some initial work on having the version sweeper create PRs, much like dependabot. I agree that could be really valuable, and it should be revisited.

In addition to the EOL-based approach, it would be cool to allow the sweeper tool to automate an issue that tracks the next major release.

Might also be cool to support manual runs that accept input for these sorts of things.

Dependabot

I think that we should auto-approve/merge dependabot PRs when all checks pass. I certainly agree with the proposals and related issues that you've linked above.

[tdykstra]

Dependabot doesn't update the TFM

Considering the number of breaking changes, and sometimes changes in recommended coding patterns, from one major version to the next, is it safe to automate upgrading the TFM?