Auto watch jpath

[wilfriedroset]

The jpath contains additional library used to manifest the dashboards. During the development workflow one might modify the underlying lib. This commit makes grr automatically watch the jpath. Moreover, a change in the jpath will trigger the reload of all watched files.

Fixes: #555

[Pokom]

Thanks @wilfriedroset for the PR! I've pulled and tested locally and think it looks reasonable. I'm going to ask @K-Phoen to take a peak as well as they have a bit more context into this part of grizzly.

I've allowed the PR to run relevant workflows as well, so you can get results from CI.

[malcolmholmes]

A few comments. Grizzly started as a Jsonnet tool, hence Jpath being an important thing. But it evolved, with Jsonnet becoming only one way of interacting with it - no other way requires jpath.

Therefore, I'd prefer it if the "blast radius" of the jpath could be limited - if there's a watchPaths, can't the jpath dirs just be added to that right from the get go, then the rest of the code needn't change (and can stay oblivious of jpath's existence)?

[wilfriedroset]

if there's a watchPaths, can't the jpath dirs just be added to that right from the get go

This is what I initially though and tested. This is how I stumble upon the unexpected behavior I've reported here: #555

My understanding is that the use of watchPaths to watch both the mixins (e.g: dashboards) and the lib cannot work as it is now. Indeed, when grizzly catch a change in the lib and not the mixins themselve, grizzly tries to manifest/build the lib which produce the error RUNTIME ERROR: couldn't manifest function as JSON

This is why I've come up with the following PR. Another idea I add while I was working on it was to add another flag, watchPathsWithoutManifests and any changes in those path would trigger the manifest/build of anything in watchPaths.

My understanding of grizzly is not as deep as I would like hence I would like your guidance @malcolmholmes about the next course of actions to fix #555