jsoo calls `caml_pasta_fp_poseidon_block_cipher` through (native ffi) ~neon-rs~ napi-rs artefact

[Trivo25]

Once we have the compile artefacts available through the build pipeline, we need to access them in o1js to call into them and execute native rust functions

• jsoo has access to native ffi neon-rs artefacts
  • Notes: currently, we inject a plonk_wasm object into o1js and the jsoo bindings for the node version as well as the web version - ideally we maintain the exact same interface and only inject the native prover artefact into the bindings via a third injection specifically for node-native (note: we definitely want to keep web-wasm and we may even consider keeping the node-wasm version as a fallback, so we don't need to change any of the existing implementations and pipelines, only add a new one for node-native)
• jsoo uses neon-rs artefact to call caml_pasta_fp_poseidon_block_cipher
• the interface we inject is currently called plonk_wasm, ideally we also refactor this part and rename it to something more generic, such as rust_interface to avoid confusion in the future
• jsoo converts data coming from js/js-compiled-from-ocaml correctly to a format that neon-rs expects
  • the conversion logic in the jsoo bindings code correctly handles native rust ffi data conversion, here's an example, the integration tests will pass if it works

// Provides: caml_pasta_fp_poseidon_block_cipher
// Requires: plonk_wasm, tsRustConversion, tsRustConversion
function caml_pasta_fp_poseidon_block_cipher(_fake_params, fp_vector) {
  // 1. get permuted field vector from rust
  var wasm_flat_vector = plonk_wasm.caml_pasta_fp_poseidon_block_cipher(
    tsRustConversion.fp.vectorToRust(fp_vector)
  );
  var new_fp_vector = tsRustConversion.fp.vectorFromRust(wasm_flat_vector);
  // 2. write back modified field vector to original one
  new_fp_vector.forEach(function (a, i) {
    fp_vector[i] = a;
  });
}

[Geometer1729]

This pr renames plonk_wasm and changes the layout to make it easier to add the rust interface
MinaProtocol/mina#16779

[richardpringle]

See this comment. I made this work last week, and have been exploring the best way to do the build here.

[richardpringle]

The module is setup with neon
https://github.com/o1-labs/proof-systems/blob/55219b0fc6ec589041545ae9470dd1edb29e3e02/plonk-neon/src/lib.rs#L13-L24

And the two functions (both fp and fq) are defined
https://github.com/o1-labs/proof-systems/blob/55219b0fc6ec589041545ae9470dd1edb29e3e02/plonk-neon/src/poseidon.rs#L13
and
https://github.com/o1-labs/proof-systems/blob/55219b0fc6ec589041545ae9470dd1edb29e3e02/plonk-neon/src/poseidon.rs#L37

The code has been tested locally and works (I think only fp is being callled in the tests, but I see no reason why one would work but not the other). The build still needs to be automated.

When building for "native," the dynamic-library or object file needs to have the file extension changed to .node for it to be imported directly from JS as follows

const plonk_neon = require('<path_to_file>/plonk_neon.node');

plonk_neon.caml_pasta_fp_poseidon_block_cipher(<args>);

Since we've only written two of the many dependent functions, one can overwrite the plonk_wasm JS object as follows:

const plonk_wasm = require('<path-to-plonk-wasm>');
const plonk_neon = require('<path-to-plonk-neon>');

// fp
plonk_wasm.caml_pasta_fp_poseidon_block_cipher = plonk_neon.caml_pasta_fp_poseidon_block_cipher
// fq
plonk_wasm.caml_pasta_fq_poseidon_block_cipher = plonk_neon.caml_pasta_fq_poseidon_block_cipher