Logging improvements

[bitdisaster]

This PR brings various improvements around logging with the main purpose of making them easier to understand for developer or CE engineers that do not have knowledge of the internals of Squirrel.

1.) Bugfix because of multiple process logging to the same file
With exemption of the --uninstall case logs get written to the location of the executing binary. During install and update scenarios the Update.exe in %localappdate%\MyApp can run in multiple process at the same time due to squirrel hooks. Previous code has tried to avoid collision but since the file was opened with ReadWrite access a collision would never happen. Instead partial or all content from one or the other process was missing. While the collision code is fixed and remains, a new naming strategy will also avoid collision (see 2.)
2.) Better Squirrel log naming
Squirrel logs leaves logs in multiple locations depending on the executing binary's location. Furthermore, log file can contain information from multiples runs of different Squirrel commands such --update, --createShortcut, etc. To make it easier to understand the content log files are now named by the invoked Squirrel command, e,g Squirrel-Update.log, Squirrel-Uninstall.log. The naming also avoids collision described in 1.)
3.) No errors/ exceptions in happy path
Even if an installation or update went perfectly, the logs contained errors/exceptions. Without deeper knowledge of Squirrel its not easy to understand whether this is of any concern. From now on the logs will be nice and shiny if Squirrel walked the happy path.
4.) Clear end of logging session
When reading the log files its not clear whether a command such as --install was executed successful. It seems like a rather sudden stop. A final log entry at the end adds some peace of mind.
5.) Add log level
While Squirrel uses log level internally they were not written to the log files. Now we will know if an entry is just and info or a warning or an error.

[anaisbetts]

This is a much better name, 👍

[anaisbetts]

Squirrel doesn't use one-class-per-file, can you put this in IUpdateManager.cs (or maybe a different file, whatever makes Sense)

[bitdisaster]

sure thing

[anaisbetts]

Into this refactor 👍

[anaisbetts]

Can you rebase against upstream master to get rid of the weird merge commits? (lemme know if this gives you Grief and I can help out)

[bitdisaster]

Yeah, those commits refuse to go away. You are not on Electron HQ anymore

[bitdisaster]

Got it done. All feedback addressed so far.

[anaisbetts]

@bitdisaster Wait one more thing, this PR breaks a public interface, can we find a way to do this without the breaking change to CheckForUpdate? Generally if the user doesn't say otherwise they're in the update scenario, the initial install scenario is generally only used internally

[bitdisaster]

🤔

[bitdisaster]

I can't think of way to get totally rid of it because at the place where I need it, I have no other context on whether its an update or install scenario. However, we could make it virtually a non breaking change by moving the parameter to the end and apply a default value. Task<UpdateInfo> CheckForUpdate( bool ignoreDeltaUpdates = false, Action<int> progress = null, UpdaterIntention intention = UpdaterIntention .Update);

[anaisbetts]

However, we could make it virtually a non breaking change by moving the parameter to the end and apply a default value

Works for me, we don't promise ABI compatibility

[anaisbetts]

👍