Reinstate running scripts through JNI connection instead of webservice for embedded engine

[NPavie]

AVH users reported issues with webservice interactions on the addin due to a possible change in how Windows handles webservice that are bound to locahost or 127.0.0.1 adresses.

It seems some firewall definitions have changed in windows updates that makes those kind of webserver triggering a firewall security notice (a small dialog asking if the application should be authorized on public, domain or private network areas).
AVH has hardened their security rules to disallow users to access this dialog, making the DAISY Pipeline 2 to raise an "Access denied" error when trying to launch the webserver.

(It also noted that the -Dcom.sun.management.jmxremote seems to also trigger this security notice on launching the pipeline)

As a temporary bypass, the following firewall rules need to be added by an admin if the addin installed on users account with such security configuration :

• rule name: SaveAsDAISY embedded engine TCP
  • Program %LOCALAPPDATA%\Apps\Save-as-DAISY Word Addin\daisy-pipeline\jre\bin\java.exe
  • Profil Public
  • All TCP ports
  • Action : blocking connections
• rule name: SaveAsDAISY embedded engine UDP
  • Program %LOCALAPPDATA%\Apps\Save-as-DAISY Word Addin\daisy-pipeline\jre\bin\java.exe
  • Profil Public
  • All UDP prots
  • Action : blocking connections

As the addin can now also use the DAISY Pipeline app, the following rules can also be added to allow its use by SaveAsDAISY

• rule name: DAISY Pipeline app engine TCP
  • Program %LOCALAPPDATA%\Programs\pipeline-ui\resources\app.asar.unpacked\resources\daisy-pipeline\jre\bin\java.exe
  • Profil Public
  • All TCP ports
  • Action : blocking connections
• rule name: DAISY Pipeline app engine UDP
  • Program %LOCALAPPDATA%\Programs\pipeline-ui\resources\app.asar.unpacked\resources\daisy-pipeline\jre\bin\java.exe
  • Profil Public
  • All UDP ports
  • Action : blocking connections

[NPavie]

Due to difficulties embedding directly jni calls in the addin itself (that was triggering memory corruptions in the JVM and blocked document handles in consecutive runs), the JNI interaction are now managed by a separate binary called "JNIWrapper".

This wrapper is launched through command line within the C# code, and forward the requested script name and options to launch the conversion through JNI calls.

This wrapper opens a dedicated WPF window to follow the conversion progression and can produce simple error logs.

The wrapper is almost complete for the task it is meant to do, except for progression indicator that are not yet retrieved and displayed : the messages system has changed a bit and previous progression messages are not reported anymore by the SimpleAPI interface of the engine.