Fix/dependabot bumps

[raharper]

What type of PR is this?

cleanup

Which issue does this PR fix:

#742
#734
#732
#730
#725
#724
#722
#708
#704

What does this PR do / Why do we need it:

Fix Critical/High/Medium CVEs against golang dependencies in stacker.

If an issue # is not available please add repro steps and logs showing the issue:

grype stacker

Testing done on this change:

make test priv and unpriv on amd64

Automation added to e2e:

none

Will this break upgrades or downgrades?

no

Does this PR introduce any user-facing change?:

Yes. Dropping stacker-bom support. The stacker-bom project is out-of-date with newer synk API which prevents updating it to newer go.mods which then keeps stacker down to be compatible with the stacker-bom go API.

Dropping stacker-bom support

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[codecov]

Codecov Report

❌ Patch coverage is 12.50000% with 28 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.17%. Comparing base (ebb4855) to head (c20d613).

Files with missing lines	Patch %	Lines
pkg/container/idmap/idmap.go	0.00%	14 Missing ⚠️
pkg/container/userns.go	0.00%	14 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #751      +/-   ##
==========================================
+ Coverage   52.84%   54.17%   +1.32%     
==========================================
  Files          59       55       -4     
  Lines        6492     5855     -637     
==========================================
- Hits         3431     3172     -259     
+ Misses       2418     2108     -310     
+ Partials      643      575      -68     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[raharper]

Need to look into the make lint failure; complains about containers/image/storage go module not being importable. However stacker-dynamic and stacker builds just fine.

/home/runner/work/stacker/stacker/hack/tools/golangci-lint/v2.7.2/golangci-lint run --build-tags "exclude_graphdriver_btrfs exclude_graphdriver_devicemapper containers_image_openpgp osusergo netgo skipembed"
Error: pkg/lib/containers_storage/lib.go:8:2: could not import github.com/containers/image/v5/storage (.build/gopath/pkg/mod/github.com/containers/image/[email protected]/storage/storage_dest.go:32:2: could not import github.com/containers/storage (-: # github.com/containers/storage
Error: .build/gopath/pkg/mod/github.com/containers/[email protected]/userns.go:334:29: undefined: securejoin.OpenInRoot
Error: .build/gopath/pkg/mod/github.com/containers/[email protected]/userns.go:340:20: undefined: securejoin.Reopen)) (typecheck)
	"github.com/containers/image/v5/storage"
	^
1 issues:
* typecheck: 1
make: *** [Makefile:130: lint] Error 1

This took way longer than I wanted. Two issues:

1. Had to move filepath-securejoin to v0.4.1 which still had these functions
2. Had to move containers/storage to v1.58.0 to deal with GetDiffer -> NewDiffer breaking API change (containers/storage@c9260b97)

[raharper]

\o/

All these go deps are rather gnarly. A little surprised at the end here that not long were we dependent on umoci compress size (fixed since umoci 0.5.0) but it seems klauspost/compress and go-mtree affect our compressed blobs.

Will clean up these sets of commits tomorrow.

Stacker at this point is squeezy clean via grype:

ubuntu@build-stacker2:~/stacker$ grype --version
grype 0.104.3
ubuntu@build-stacker2:~/stacker$ grype stacker
 ✔ Indexed file system                                                                  stacker
 ✔ Cataloged contents          57747f80a24ceeb3f2e6499f0cde785761a752e4dbe4f0d7a6bd58e2ad42efb0
   ├── ✔ Packages                        [126 packages]
   ├── ✔ Executables                     [1 executables]
   ├── ✔ File digests                    [1 files]
   └── ✔ File metadata                   [1 locations]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
No vulnerabilities found