Update labels when config changes

[rarkins]

Describe the proposed change(s).

Renovate should be able to support changing of labels in an existing PR, as long as the user hasn't modified the labels Renovate originally added.

We don't want to be in a situation where users remove/change labels and Renovate keeps putting them back. To avoid that, we can potentially embed a hash in the PR body which records which labels were added to the PR originally, or when they were last updated. If all such labels are still in the PR, then we should be free to update/sync the labels (including adding and removing).

Describe why we need/want these change(s).

Examples:

• user modifies their config to add labels, when previously there were none
• user has labels for dynamic fields like updateType or confidenceLevel

It's unintuitive today why changes can't be made in these situations.

[secustor]

Duplicate of #9950 ?

[rarkins]

Seems to be related, but a different idea. Perhaps we use my idea above but could add a new option updateLabels with values never (current behavior), auto (new default), and always (enforced)?

[PhilipAbed]

i think you are inviting more problems and complexity by deciding if it is updated manually or by renovate,
why dont we just create a param to override labels=true and only if the user requested this param then we do it on open PRs?

[rarkins]

Reasons:

1. This is desired behavior to have by default
2. It's necessary to also be able to remove labels (consider merge confidence labels as an example)
3. It wouldn't be OK if Renovate always removed any user label which was added

Hence we need to be able to distinguish between these two cases:

• A label is additional or missing because config changed, or
• A label is additional or missing because the user removed it

[secustor]

In that case we should basically add a hidden string inside of PRs/Issues to save the last applied labels.
Pretty much like the debug information we have right now.

[rarkins]

A hidden string would be simpler, a hash of that string would be shorter

[RahulGautamSingh]

If we use pr-comments we can only enable this feature for github, gitlab and gitea.

Update:
Only azure is left out since we don't set labels on others ie. codecommit, bitbucket, bitbucket-server

We can handle azure but there is a catch:

issue	the azure api endpoint that we use to fetch PRs returns PR but has a 400 char limit on its description
workaround	set the comment with labels at top of Pr body

[rarkins]

Actually if the "hidden strings" are short hashes, I think we could make them non-hidden for platforms which don't support html comments if the functional benefits outweigh the "costs" (extra lines in the PR description)

[RahulGautamSingh]

Okay, also it has to be done in 2 PRs so that the hash is added to all existing PRs before we start adding/removing labels.
Else we will reapply labels which can annoy users who have removed some labels from open PRs. (or is this okay?)

[rarkins]

We should only reapply labels to existing PRs if that PR was created with a label hash, so that we don't annoy users who have removed labels

[RahulGautamSingh]

Is this not ready?

[rarkins]

We no longer use status:ready - if an issue has no status:* label then it's ready