Expose custom backend option thru bbjs

[ludamad]

The code is almost set up for this. You can create a new Barretenberg(your_custom_backend) API instance, pass it to an e.g. UltraHonkBackend and have a functioning bbjs API with custom msgpack transport.

However, looking at this code section:

export class Barretenberg extends AsyncApi {
  private options: BackendOptions;

  // ->> why does backend not have the backend options built in?
  // TODO would be good to refactor this so a custom backend can be used
  constructor(backend: IMsgpackBackendAsync, options: BackendOptions) {
    super(backend);
    this.options = options;
  }

There is also BarretenbergSync that takes a IMsgpackBackendSync.

There is awkwardness where we expose this custom backend type Barretenberg then also has an enum in options for a few select backend types

We should create a test, ensuring the dev experience is as smooth as possible, and implement a custom backend there. One example that comes to mind is a IMsgpackBackendAsync implementation that is simple HTTP server that takes msgpack over a /bbapi endpoint and returns msgpack back. We should have another case replacing IMsgpackBackendSync with something trivial. It can be enough to just make a backend that throws a specific error and catch that error, as an interesting sync API is hard to think of (and just wiring back to WASM isnt that interesting).

[ ] Move away from these enum options in Barretenberg OR at least provide an enum option that corresponds to custom backend async and custom backend sync
[ ] Think about the best way to replace the sync and async APIs. Look into how they are currently instantiated and what it means to make bbjs fully use custom backend(s). We need to make sure we can hook into any initialization code of these backends
[ ] Have a test that demonstrates a custom backend (can be trivial) that replaces the sync API and one that replaces the async API