Remove NIOPosix as a dependency of our library targets

[Lukasa]

In #1935 I removed NIO as a dependency of a number of our library targets. This unfortunately led to some downstream breakage in modules that were (incorrectly) assuming they could import NIO without expressing a dependency on it in their Package.swift, e.g. swift-server/swift-aws-lambda-runtime#218.

While a forums thread (https://forums.swift.org/t/semantic-versioning-should-removing-a-dependency-be-a-semver-major/51179) is ongoing to discuss the implications of this, we re-added the dependency to our library targets in #1937. Based on the outcome of that thread, we should determine when the appropriate event is to remove them, and do so.

For now I'm filing this as a major and scheduling it for 3.0, but if the thread concludes that earlier is suitable, we may bring this forward.

[PeterAdams-A]

Alternative would be to wait until https://github.com/apple/swift-package-manager/pull/3562 is done and we no longer support swift versions before that.

[daprice]

I’m working on an app that depends on NIOHTTP1, and I’m getting warnings when submitting it to app review about using privacy-sensitive file timestamp APIs (NSPrivacyAccessedAPICategoryFileTimestamp). As far as I can tell, this is coming from the fact that NIOHTTP1 still depends on NIOPosix which calls some of the API that Apple lists as sensitive.

Since privacy manifests don’t allow declaring API that we include but don’t intend to use, a way to use NIOHTTP1 without also getting NIPosix would be very much appreciated!

[Lukasa]

Ah this is a good call-out, and quite unfortunate. We may have to do a fairly horrible workaround here to get out of this situation.