fix: remove read lock from config get

[mkhq]

What this PR does / why we need it:

This removes the lock when reading from a global or local config file. The read lock can lead to dead-lock in situations where we trigger concurrent reads, e.g. in projects having multiple modules with linked sources. @nilium has provided a reproducible example here: https://github.com/nilium/garden-locker, see discord thread for more details: https://discord.com/channels/817392104711651328/1151269956240031826

Is it safe to remove the read lock?

• Concurrent reads are safe since they don't modify the state of the config.

• Writes need the lock since they perform a read + write of the config, which in the case of concurrent writes could result in a trace with R1, R2, W2, W1. Process 1 overwrites the values from process 2 leading to a potentially incorrect state.

• Write operations are atomic, we either read the state before or after the write. A concurrent read should not be able to read a partial state of the config.

• Config data is always validated against the schema and throws an error in case of failure.

Note of caution

• Since this happened for concurrent reads, it will also happen for concurrent writes. In the example project provided by @nilium (https://github.com/nilium/garden-locker), there were in total 12 modules with remote sources (referenced by repositoryUrl).

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

[nilium]

Confirming this fixes the lock file error that prevented Garden 0.13 from working here. I can't comment on the safety of removing the read lock, so have to leave that to others, but it's nice to see 0.13 working here considering the other improvements that brings.

[stefreak]

I agree with your conclusions about safety, if writeFileAtomic works as intended on all supported platforms.

[TimBeyer]

Are file write operations atomic? The node docs say this:

It is unsafe to use fsPromises.writeFile() multiple times on the same file without waiting for the promise to be settled.
Similarly to fsPromises.readFile - fsPromises.writeFile is a convenience method that performs multiple write calls internally to write the buffer passed to it.

I assume that the chances of reading a partial file are small, but are they zero?

[TimBeyer]

Ah ignore my comment, I didn't realize we're actually using writeFileAtomic which Steffen mentioned.
No concerns from my side then.