Revert "ci: setup ossf scorecard and codql workflows"

[casualjim]

Reverts #3049

[fredbi]

@casualjim I am proposing to take care of this by reverting more selectively.

1. tame dependabot to avoid the overwhelming flurry of PRs
   • monthly scans, automatic approve&merge with minimal CI when only github actions are involved
2. remove the score card. The results cannot be viewed anyway (the link under the badge does not work)
3. keep the github code scan (at least for some time). It is always interesting to watch if something interesting comes out of it

Overall we agree on principle: let's not allow this thing to become a work generator.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (479c51b) 32.55% compared to head (b6b31b0) 82.64%.

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #3056       +/-   ##
===========================================
+ Coverage   32.55%   82.64%   +50.09%     
===========================================
  Files          60       62        +2     
  Lines       12803    12856       +53     
===========================================
+ Hits         4168    10625     +6457     
+ Misses       8296     1692     -6604     
- Partials      339      539      +200     

Flag	Coverage Δ
codegen-oldstable-canary-fixtures	32.55% <ø> (ø)
codegen-stable-canary-fixtures	32.55% <ø> (ø)
unit-oldstable	82.79% <ø> (?)
unit-stable	82.79% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fredbi]

@casualjim I've resolved the merge conflict and re-added 2 things that I've found interesting to continue experimenting with: the codeSQL scan and the "security score cards" (a kind of linter for "opsec best practices). The report is eventually available (it took a day to set up, but now it's there) and the findings, if not necessarily relevant to our use-case, are interesting to analyze and be reflected upon.

https://securityscorecards.dev/viewer/?uri=github.com/go-swagger/go-swagger

Maybe we'll eventually decide to disable this scorecard if it turns out to be really not suited to our project, but for the moment I am still curious about the recommendations.

I've removed dependabot and the by-commit-sha pinning for now. I think that @mmorel-35 raised an interesting point, but the PR did not come with a complete solution, just more problems to solve in the short term and more work until we find an appropriate solution to maintain our dependencies with minimal burden. So, statu quo for now, I need more experimentation on my fork.

@mmorel-35 I have to thank you for having raised an interesting point. However yesterday's experiment proved not to be very successful: as soon as the stuff was merged, we already had about 5 such update PRs, stalling all our CI for hours.

This started a fascinating conversation with @casualjim about the extra workload that comes from all those update bots...

If we eventually move to such kind of automation, it will have to be more carefully designed and discussed beforehand.

Another contributor has suggested a dependabot setup to some of the go-openapi repos. The problem to solve for those repos is different, but still, we don't want to use many different tools.

[fredbi]

NOTE: I've updated those damned actions, so the bot PR's should disappear automatically.