Copy the mtime on puppet generate types

[ekohl]

When installing a new module it can maintain the file timestamps from the original tarball (like g10 does). puppet generate types uses the timestamp of when it ran.

If you update a module to a release that was created before it ran puppet types generate, it will never update the types. This can happen with a module downgrade, or just when you regenerated types manually. By using --force the timestamps are ignored, but that's only a workaround.

This new approach copies the mtime from the source file to the generated cache file. It is only considered up to date if the mtime matches.

Reviewer notes:

• I haven't had a chance to test this yet, so take that into account
• It does a stat twice now - this could be cached
• It's relying on the implicit mtime comparison (using <=> on File::Stat) while in copying it is explicit - should this be changed in comparison?

[puppetlabs-jenkins]

Can one of the admins verify this patch?

[ekohl]

The test failure is in related code, but the error message lacks detail.

[joshcooper]

Thanks @ekohl! I've been bitten by this issue too when downgrading a module. The test is failing because it assumes puppet generate types --force will always update the mtime of the generated files

Of course, that's no longer true, since the generated file's mtime is set to whatever the input file's mtime was. I think the test would need to be modified to verify the mtimes are the same, but the File::Stat('..').ino are different (and maybe skip the test on Windows)?

Also @jonathannewman and @justinstoller would this introduce/cause problems for code manager?