Add check for .env.local and module bindings generations to only write on changes

[aceysmith]

Description of Changes

The spacetime dev and spacetime generate commands always overwrite the .env.local and module_bindings files, even if the contents are identical. This can be a nuisance if your client is watching for changes and reloading, as spacetime dev will modify both of those at different times in the process.

This change will first read the contents of the files and see if a write is necessary.

For writing .env.local as part of spacetime dev, the file contents were already read so no real impact should exist.

For module_bindings, I've done some initial profiling with 181 generated typescript files and separately 161 rust files and noticed no performance impact.

API and ABI breaking changes

None

Expected complexity level and risk

1

Testing

I've ran this code on a project that generates 181 source files for typescript and 161 for rust. It correctly writes files when changes have been made and leaves the files unmodified if no changes are made.

For review testing, I would recommend running both with and without my change on a much more complex project if it's available. I would think not writing the contents of each file would mitigate the cost to read most of the time, but perhaps in certain project makeup scenarios and storage performance characteristics, this could possible be marginally slower sometimes, though I have not observed that to be the case.

[cloutiertyler]

The behavior is slightly different than in the dev command. Since in the following

    let mut contents = if env_path.exists() {
        fs::read_to_string(env_path)?
    } else {
        String::new()
    };

if the file exists but there is file read error we will not write the file out, for example PermissionDenied which would cause the program to try to write even if it can't read. Could you modify this to have the same behavior as above?

[aceysmith]

Wouldn't the expectations for the two types of files be somewhat different?

If .env.local exists but we can't read it, we shouldn't clobber over the existing file contents and should exit with error. spacetime dev (likely) isn't the only source of changes to that file.

For module_bindings however, this spacetime generate/dev IS likely the only source of changes. If we can't read the file, that's probably fine and we should attempt to write it still.

If you want, I can still make the change so that if a module_binding file exists but is unreadable, we exit out. That scenario is definitely an edge case so I see the value in making it consistent with how .env.local is handled.

[cloutiertyler]

Requested a small change, but otherwise would love to merge this.