Update to newer SwiftPM dependency

[finestructure]

In the course of trying to debug #3755 I've noticed that we're still tracking release/5.10 for SwiftPM. Updating this isn't entirely trivial, because it triggers concurrency errors in our packages CanonicalPackageURL and DependencyResolution, which aren't Swift 6 ready yet.

[finestructure]

This might actually be a blocker to the progress of debugging #3755, because I can't use a fork of Vapor unless I either remove SwiftPM as a dependency or update it. It's creating a conflict with existing uses of Vapor (the original). Alternatively, I'd also have to fork all of these dependencies.

error: Dependencies could not be resolved because 'swift-package-manager' depends on 'swift-system' 1.1.1..<1.4.0 and 'vapor' depends on 'swift-nio' 2.81.0..<3.0.0.
'swift-nio' >= 2.81.0 practically depends on 'swift-system' 1.4.0..<2.0.0 because 'swift-nio' 2.81.0 depends on 'swift-system' 1.4.0..<2.0.0 and no versions of 'swift-nio' match the requirement 2.81.1..<3.0.0.
warning: 'redis': 'redis' dependency on 'https://github.com/vapor/vapor.git' conflicts with dependency on 'https://github.com/finestructure/vapor.git' which has the same identity 'vapor'. this will be escalated to an error in future versions of SwiftPM.
warning: 'fluent': 'fluent' dependency on 'https://github.com/vapor/vapor.git' conflicts with dependency on 'https://github.com/finestructure/vapor.git' which has the same identity 'vapor'. this will be escalated to an error in future versions of SwiftPM.
warning: 'soto-cognito-authentication': 'soto-cognito-authentication' dependency on 'https://github.com/vapor/vapor.git' conflicts with dependency on 'https://github.com/finestructure/vapor.git' which has the same identity 'vapor'. this will be escalated to an error in future versions of SwiftPM.

The real issue is that we need to depend on SwiftPM for the package collection module. I remember asking for it not to live inside SwiftPM. It's biting us now.

[finestructure]

This is actually quite bad. We've stopped tracking Vapor's releases because the SwiftPM dependency held us back. We're on 4.106.4 from Nov 22, 2024:

SwiftPackageIndex-Server/Package.resolved

Line 568 in b4d086d

"version" : "4.106.4"

Current latest release is 4.114.1. That's bad given how important a package Vapor is.

The reason we don't see this is that SwiftPM doesn't have semantic versions that can be tracked by dependabot.

[finestructure]

Also, updating to SwiftPM release/6.0 also won't help:

error: Dependencies could not be resolved because root depends on 'vapor' 4.114.1..<5.0.0 and 'swift-package-manager' depends on 'swift-system' 1.1.1..<1.4.0.
'vapor' >= 4.114.1 practically depends on 'swift-system' 1.4.0..<2.0.0.
'swift-nio' >= 2.81.0 practically depends on 'swift-system' 1.4.0..<2.0.0 because 'swift-nio' 2.81.0 depends on 'swift-system' 1.4.0..<2.0.0 and no versions of 'swift-nio' match the requirement 2.81.1..<3.0.0.
'vapor' >= 4.114.1 practically depends on 'swift-nio' 2.81.0..<3.0.0 because 'vapor' 4.114.1 depends on 'swift-nio' 2.81.0..<3.0.0 and no versions of 'vapor' match the requirement 4.114.2..<5.0.0.

release/6.1 fixes this. So, we need to move to Swift 6.1 in order to unpin Vapor.

Immediately after that, I think we must drop SwiftPM as a dependency or convince the maintainers to move the package collection parts we need into a standalone package that can have semantic releases.

[finestructure]

The reason we don't see this is that SwiftPM doesn't have semantic versions that can be tracked by dependabot.

Actually, I don't think that's true. It's just that SwiftPM is a huge dependency with critical constraints of which we use a tiny part. It's not getting frequent releases that would appear in dependabot and allow this to be moved forward automatically though. So it's on us to make sure we do (it wouldn't have helped here, because only 6.1 unpins the critical constraint).

Essentially, SwiftPM is too big a package to depend on given what we need from it. And, critically, it's not actually a package intended to be used as a dependency. I think that's the part we should have stressed more when discussing where the package collection details could/should live.

[finestructure]

Closed by #3761