`testgen-hs`: load it as a shared library? `.so`/DLL/`.dylib`?

[michalrus]

Context

We have a lot of ceremony to make sure that the two binaries can communicate correctly, nobody killed the child etc.

Especially after:

• Tx evaluation #378

Why not load testgen-hs.so as a dynamic object instead, and have the operating system do what it does best?

There's not a lot of communication points, they could even still use JSON over a few short functions.

There's been some project in IOG that already made this work, but a JSON communication we could probably even hack ourselves.

[ginnun]

This became a more pressing need after #490, since it re-spawns testgen-hs if node config is changed on each epoch boundry.
Handling re-spawning of testgen-hs in a load bearing production environment is an unnecessary complication.

I can look into this after merging #378 and #490 into master.

[michalrus]

One tricky thing is that we'd have to start the Haskell RTS (Runtime system) properly within our binary, for the Haskell code to run.

[michalrus]

Also: a separate binary has this advantage that we can restart it to clear RAM? In case of leaks, which are not hard to cause in Haskell

[michalrus]

Another point: an SPO might want to not run the tx eval endpoints for whatever reason (e.g. to not run Haskell code?)