[feature] Add support for hot reloading

[c12i]

This is a follow up from the original spike https://github.com/holochain/scaffolding/issues/394

Here are some findings I made that could make this achievable:

• Configuration: hot reloading could be configured with a flag and an option in the hc-spin cli: --hot-reload would enable hot reload and --watch-dir would instruct the file watcher which directory/ glob to watch for changes for example the ./dnas dir.
• Integrating a file watcher. In node.js, chokidar looks like a very good option and it provides cross-platform support.
• Putting it all together:

  if (cli.opts().hotReload) {
    const watcher = chokidar.watch(cli.opts().watchDir, { persistent: true });
    watcher.on('change', async (file) => {
      console.log(`${file} has changed`);
      childProcess.execSync('cargo build --release --target wasm32-unknown-unknown');
      childProcess.execSync('hc app pack workdir --recursive');
      // more steps
    });
  }

The code snippet above shows how we can initialize a file watcher and listen for change events where the hot reloading logic would live. From my understanding, this would be the correct sequence of events, feel free to correct me if I miss anything:

• Rebuild wasm
• Pack app
• Save newly built happ or webhapp
• Via admin ws: disable previously running app
• Via admin ws install new app

I have only been able to test out the the first two steps, I ran into some issues calling the rustUtils function to save the happ or webhapp, I believe you have better understanding on how we would go about with the next steps or if there's anything I missed there that should probably be done too.

Some caveats with the proposed approach though, there is still no way to ensure that saved data is persisted between hot reloads, I think this can be a problem we tackle later one though once we get hot reloading working. Additionally, we cannot guarantee that the dna hash will remain the same across hot reloads, I am not sure this would be a problem while developing though, but this can be worked around by specifically setting the --watch-dir as the path to the coordinator zome source code.

Let me know what you think.

[matthme]

You'd also need logic to reconnect to the app websocket in the frontend. It will use an authentication token that was bound to an app that does not exist anymore so the UI should start failing I think. I don't know how to solve that part without adding some special logic to the js-client which I think seems problematic.

[matthme]

Not sure though...maybe a page reload is enough and the js-client would read the new parameters from the window object.

[matthme]

But they would need to be updated there somehow. This logic of writing connection parameters to the window object is currently part of the preload script I think.