Reevaluate symbol request lifetime

[hoyosjs]

• [ ] This issue is blocking
• [x] This issue is causing unreasonable pain

Right now, symbol requests are allowed to live for too long. In just a few months we've generated 20TB of symbol data that's to live for 10 years. Most of these symbols are not necessary. We should change it to the following:

• Channels/repos that are contributing to the current UB main, symbols are retained for 90 days
• Release branch channels of regular channels retain 6 months per build.
• Release branch channels of tools channels retain 10 years.
• Staging and release pipeline retain for 10 years as we currently do.

@jaredpar @marcpopMSFT do these line up well for insertion scenarios?

cc @mmitche

[marcpopMSFT]

For tooling repos, I believe most tools that ship in the SDK and VS GA versions fork their branches before the final builds. This is not always true iirc (I think some repos like deployement-tools just ship to us from main but we should double check the full list) but perhaps we can make it a requirement. They all have different naming conventions though. The SDK is release* or internal/release/* (noting that release/* don't need to last 10 years as that's just for previews).

MSBuild is vs17., NuGet is release-6..x, etc. If those tooling repos are included in this, you'll need to develop a heuristic or have them change their naming convention.

[jaredpar]

The only symbols I would care about long term are builds that come from release branches. Everything else, don't think we need to keep them more than 3-6 months. Is there a way to filter symbols that come from release/*? If so think it's easy to say that release builds need to come from release/* branches.