Dependency cooldown policy

[sigurdm]

An attempt at #4791

Projects can declare a policy block in their pubspec.yaml.
At most one policy definitions is allowed across workspace members to prevent conflicting policies.

For now the only policy is a "cooldown" that restricts which dependencies a package is allowed to take.
Language version needs to be at least 3.13 for a policy to be definable.

Configured by:
min_age : The minimum age duration a package version must have (e.g., 7d, 2w).
before (One of before and minAge must be specified): a timestamp with timezone specified.
exclude (Optional): A list of package names that are exempt from the cooldown policy.
stability (Optional , can only be applied with min_age): A boolean flag that blocks package versions if a newer version is published within the cooldown window after its release (indicating a rushed bugfix/unstable release).

Why we have "stability" When a library author publishes a release (e.g., 1.0.0) and quickly follows up with another release (e.g., 1.0.1) within a short window, it strongly suggests that the initial release had a critical regression, compilation failure, or major bug. Resolving to 1.0.0 in this window exposes your project to an inherently flawed/unstable release. Enabling stability: true ensures your solver skips intermediate releases that triggered emergency follow-ups, keeping your dependency graph robust., however this is different from the behavior of most ecosystems corresponding feature. So we keep this optional and off-by-default.

Example:

name: myapp
environment:
  sdk: ^3.13.0
policy:
  cooldown:
    min_age: 7d
    exclude:
      - path # this package is allowed to break the cooldown policy
    stability: true

The policy only targets hosted dependencies.

Updated the protocol documentation to specify the published property as optional (but corresponding to what we do on pub.dev).

Third-party package repositories providing a published property in their version listing will be able to interact with this feature. If they don't provide it, all their non-excluded packages will be blocked from being part of the resolution.

The version solve is restricted from selecting hosted packages that violate the cooldown or stability rules.

Attempts to provide a descriptive version solving failure message indicating the specific version, its release age, and the policy's source location.

When version solving fails due to the cooldown policy, pub suggests excluding the blocked package from the cooldown policy in pubspec.yaml.

$ dart pub get
Resolving dependencies...
Because myapp depends on both bar 1.0.0 and foo any, version solving failed:
  myapp depends on bar 1.0.0 which depends on foo >1.0.0.
  version 1.0.1 of foo is too new (released less than 7 days ago)
  Cooldown policy defined at pubspec.yaml:6
You can try one of the following suggestions to make the pubspec resolve:
* Consider excluding "foo" from the cooldown policy in your pubspec.yaml.
* Try upgrading your constraint on bar: dart pub add bar:^2.0.0

pub outdated: Flags and lists versions that are blocked by the cooldown policy with a descriptive warning: Version X is too new for cooldown policy.

Showing outdated packages.
[*] indicates versions that are not the latest available.
Package Name  Current  Upgradable  Resolvable  Latest
foo           1.0.0    1.0.0       1.0.0       1.0.1*
foo
    Version 1.0.1 is too new for cooldown policy.

pub get Report: Displays available newer versions blocked by the policy next to the resolved packages (e.g., (X available (blocked by cooldown))).

+ foo 1.0.0 (1.0.1 available (blocked by cooldown))

[sigurdm]

Thanks for the review @mosuem! I've addressed all the feedback: simplified cutoff dates to UTC-only ISO 8601 strings, split CooldownPolicy into dedicated named constructors, modernized the YAML parsing and solver logic to use Dart 3 pattern matching, added missing dartdocs/comments, and added date parsing tests.