Fix executable bit lost on package data files that double as modules

[afonsojanu]

Summary of changes

Since setuptools 84.0.0, a package data file whose name ends in .py can lose its executable permission bit when it ends up in a wheel. It's a double-copy issue: such a file gets copied into build/lib twice on its way there, once through build_module() (which treats it as an ordinary module and doesn't preserve mode) and once through build_package_data() (which does ask for mode to be preserved). Both target the exact same path.

copy_file() skips its own copy once source and target already agree on mtime. The first copy already brought them into agreement (via preserve_times), so by the time the second, mode-preserving copy runs, it sees nothing to do and returns before ever reaching the code that fixes the mode. Whatever mode the first copy left behind (the OS default for a newly created file) is what survives into the wheel.

build_package_data() now forces its own copy the same way self.force already does for other commands, since it needs to be authoritative about a package data file's final state no matter what an unrelated earlier copy left on the same path.

I bisected this to the "Sync with distutils @ e8eb878" merge (#5292), specifically the pypa/distutils#379 mtime fix: preserving mtime with full nanosecond precision (rather than the previous, less exact copy) is what made the two copies' timestamps compare as exactly equal, which is what makes copy_file()'s update-skip trigger on the second one. The underlying double-copy-with-different-preserve_mode-settings issue looks like it predates that, just masked by imprecise timestamp comparisons before.

Closes #5296

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[afonsojanu]

Closing this in favor of #5319, which I opened separately for the same issue. Ended up investigating this from two directions at once and only caught the overlap after both were already up. #5319's fix is more targeted: it copies the mode directly instead of forcing the whole file through copy_file's update check, which avoids re-copying package data that's genuinely already up to date. Sorry for the duplicate noise.