LTS awareness

[rarkins]

Describe the proposed change(s).

Today in several ecosystems we treat LTS as stable and non-LTS as unstable. We should change this so that LTS and stable are different concepts and able to be controlled separately.

• Add an optional isLts boolean flag to releases returned from datasources. If a datasource has LTS awareness then it should return a value (true or false) for isLts for all releases.
• Apply these changes to the node-version datasource so that it no longer returns isStable and instead returns isLts using the same logic
• Add new, optional isLts() function to versioning modules which returns a boolean result
• Rewrite debian versioning so that the isStable() no longer returns true because a release is non-LTS, instead add an isLts() function which uses that logic
• Model new isLts logic in the worker modules on isStable, e.g. a function called isReleaseLts() which can return true, false or null
• Add a new repo config option updateToNonLts which defaults to "auto" but has options "always" or "never"
  • If auto, it means that releases with itLts=false will be ignored unless the current version/release also has isLts=false
  • If always, it means that all releases are allowed, and isLts is ignored
  • If never, it mans that releases with isLts=false are always ignored, no matter what
  • Option has no effect if the datasource/versioning has no LTS awareness

[HonkingGoose]

I found another issue that seems a bit related, it mentions LTS anyways:

• 9716

[rarkins]

Add new optional field to datasource results (per release/version): lts true/false. Add new config option respectLTS which is true by default and means: "If currently on an LTS release, do not propose any non-LTS updates".

[HonkingGoose]

This discussion about "helping JS library authors to bump their Node.js engines values whenever there's changes in Node LTS" seems relevant to this issue as well. So I'll link it below:

• 28384