Adopt FoundationEssentials instead of Foundation where available

[t089]

Use FoundationEssentials if available.

Checklist

• I've run tests to see all new and existing tests pass (macOS and linux)
• I've followed the code style of the rest of the project
• I've read the Contribution Guidelines
• I've updated the documentation if necessary

If you've made changes to gyb files

• I've run .script/generate_boilerplate_files_with_gyb and included updated generated files in a commit of this pull request

bash .script/generate_boilerplate_files_with_gyb
bash: .script/generate_boilerplate_files_with_gyb: No such file or directory

Motivation:

Would be great that packages that depend on swift-crypto can be built without linking full Foundation.

Modifications:

This patch simply replaces import Foundation with a conditional import FoundationEssentials.

In some files this also required to explicitly import the C standard lib.

Maybe we could follow the same approach as in https://github.com/swiftlang/swift-tools-support-core/blob/main/Sources/TSCLibc/libc.swift and add an internal module that abstracts this import dance in a single place.

Result:

After this change the package should only depend on FoundationEssentials.

[Lukasa]

Thanks for this! This is a worthwhile change but we have to be careful with merging it, as it requires a semver major due to Swift’s “leaky” imports.

[t089]

Thanks for this! This is a worthwhile change but we have to be careful with merging it, as it requires a semver major due to Swift’s “leaky” imports.

hm, not sure I follow. Are you saying, import Foundation makes the public Foundation API available to clients? Isn't this what @_exported import is for?

[Lukasa]

It doesn’t make the full API available, but it makes some things available. An example of one such problem is available at https://forums.swift.org/t/pitch-fixing-member-import-visibility/71432.

The Swift team consider this a bug, and I agree, but our semver policies take the language as it is, not as it is intended to be. So this will require us to burn a major.

The good news is that a) this will be a “cheap” major, as most codebases won’t be affected and so they can use a both-major range, and b) we have to do one anyway. So we’ll definitely make this change, I just wanted to clarify that it won’t be immediately merged.

[t089]

@Lukasa would a package trait help us here?

[Lukasa]

Not really, the impending major is enough.