fix(renovate): improve lockfile maintenance and tidy config

[wpessers]

Context
We've been having issues on the lockfile maintenance PRs where the current renovate config causes an infinete loop. This causes a high amount of spam notifications for maintainers, and more importantly consumes a huge amount of unnecessary gh actions minutes.

Solution

• Removed gitignoredAuthors: renovate will now stop pushing after the custom tidy workflow has ran and the commit attributed to otelbot user has been pushed. This is the actual fix, the ignored authors config is what caused renovate to keep force pushing before.
• Replaced gomodTidy by gomodTidyAll in the post update options config. This is a recent new feature in renovate, see: https://docs.renovatebot.com/golang/#monorepo-tidying-for-local-replace-directives and feat(gomod): add gomodTidyAll option for indirect dependency updates in Go monorepos renovatebot/renovate#37138
  The gomodTidy used to tidy only the specific module that received an update and leave all the others where it's used with replace directives stale. e.g.:

  opentelemetry-lambda/collector/go.mod

  Lines 5 to 13 in 3000cda

  	replace github.com/open-telemetry/opentelemetry-lambda/collector/lambdacomponents => ./lambdacomponents
  	replace github.com/open-telemetry/opentelemetry-lambda/collector/lambdalifecycle => ./lambdalifecycle
  	replace github.com/open-telemetry/opentelemetry-lambda/collector/processor/coldstartprocessor => ./processor/coldstartprocessor
  	replace github.com/open-telemetry/opentelemetry-lambda/collector/processor/decoupleprocessor => ./processor/decoupleprocessor
  	replace github.com/open-telemetry/opentelemetry-lambda/collector/receiver/telemetryapireceiver => ./receiver/telemetryapireceiver

  
  I'm thinking this might fix the issue alltogether since we wouldn't even need the github action to run, the go.mod files would all already be clean.
• Only update minor and patch versions in the lockfile maintenance, "updating" majors of indirect deps is a no-op but it has the side-effect of gomodTidy not being run because renovate thinks the branch contains an update major version.

[tylerbenson]

LGTM, but lets get @thompson-tomo to take a look.

[thompson-tomo]

I think removing this is not necessary as it stops the rebase frequency but does so by putting the pr in an edited state blocking updates and then it potentially error if more updates become available. See below for an alternative.

The issue is renovate is seeing that it is out of date as a transitive has changed hence it triggers a force push to update those transitive.

[thompson-tomo]

I would suggest adding rebasewhen to reduce when the rebase occurs by setting it to behind-base-branch

[thompson-tomo]

I am not following

Only update minor and patch versions in the lockfile maintenance, "updating" majors of indirect deps is a no-op but it has the side-effect of gomodTidy not being run because renovate thinks the branch contains an update major version.

Is what you are thinking is that the presence of a major triggers gomodTidy to not be run?

I would be inclined to leave but instead adjust when the rebase is done as well as adjust the postupdateoptions.

[thompson-tomo]

Looking at the logs, https://developer.mend.io/github/open-telemetry/opentelemetry-lambda/-/job/01a00d17-448a-7bb4-94dc-309930aa60b6 it looks like part of the issue is when renovate runs goModTidy it is failing with an error. What i can't tell is why it fails when run by renovate but ok as a ci job.

The only thing it could be is that the workflow is not checking exit Code. We could add the gomodTidyE option to renovate in addition to goModTidyAll and see if that decreases lines changed by the workflow.