feat: add env var VM_JOB_QUEUE_SHARED for tests

This adds a kind of turbo-mode for running unit tests.

Normally the job-queue is a shared singleton instance.

When running unit tests, a shared instance has these characteristics:

1. tests must wait for each other's jobs to complete. CPU usage tends to
   be low for much of the testing duration.
2. it is possible to run all tests in parallel and generate proofs when
   proofs do not exist in local cache or on proof-server.
3. total time for running all tests increases substantially compared to
   scenario where each test using its own job-queue instance.

A non-shared instance has these characteristics:

1. tests run independently and use up all CPU cores.
2. it is not possible to run all tests in parallel and generate proofs
   as it would exhaust device's resources, especially RAM.  This mode
   only works well when proofs are already cached.  A workaround is to
   run with --test-threads 1 to generate proofs.
3. total time for running all tests decrease substantially (assuming
   proofs are cached) vs the shared-instance scenario.

When running unit tests, shared mode is the default. The mode can now
be selected at runtime via:

```
VM_JOB_QUEUE_SHARED=false cargo test <args>

VM_JOB_QUEUE_SHARED=true cargo test <args>
```

Author: dan-da

src/triton_vm_job_queue/mod.rs

@@ -34,12 +34,60 @@ impl DerefMut for TritonVmJobQueue {
 }
 
 impl TritonVmJobQueue {
-    /// returns the triton vm job queue (singleton).
+    /// returns the single, shared triton vm job queue (singleton).
     ///
     /// callers should execute resource intensive triton-vm tasks in this
     /// queue to avoid running simultaneous tasks that could exceed hardware
     /// capabilities.
+    #[cfg(not(test))]
     pub fn get_instance() -> Arc<Self> {
+        Self::get_instance_internal()
+    }
+
+    /// returns a triton vm job queue.
+    ///
+    /// By default, the returned queue will be a shared singleton instance.
+    ///
+    /// When running unit tests, a shared instance has these characteristics:
+    ///
+    /// 1. tests must wait for each other's jobs to complete. CPU usage tends to
+    ///    be low for much of the testing duration.
+    /// 2. it is possible to run all tests in parallel and generate proofs when
+    ///    proofs do not exist in local cache or on proof-server.
+    /// 3. total time for running all tests increases substantially compared to
+    ///    scenario where each test using its own job-queue instance.
+    ///
+    /// A non-shared instance has these characteristics:
+    ///
+    /// 1. tests run independently and use up all CPU cores.
+    /// 2. it is not possible to run all tests in parallel and generate proofs
+    ///    as it would exhaust device's resources, especially RAM.  This mode
+    ///    only works well when proofs are already cached.  A workaround is to
+    ///    run with --test-threads 1 to generate proofs.
+    /// 3. total time for running all tests decrease substantially (assuming
+    ///    proofs are cached) vs the shared-instance scenario.
+    ///
+    /// When running unit tests, shared mode is the default. The mode can be
+    /// selected at runtime via:
+    ///
+    /// ```text
+    /// # disable shared queue (each test gets it's own queue)
+    /// VM_JOB_QUEUE_SHARED=false cargo test <args>
+    ///
+    /// # enable shared queue (default behavior)
+    /// VM_JOB_QUEUE_SHARED=true cargo test <args>
+    /// ```
+    #[cfg(test)]
+    pub fn get_instance() -> Arc<Self> {
+        let shared = std::env::var("VM_JOB_QUEUE_SHARED").unwrap_or_else(|_| "true".to_string());
+
+        match shared.as_str() {
+            "false" => Arc::new(Self(JobQueue::<TritonVmJobPriority>::start())),
+            "true" | &_ => Self::get_instance_internal(),
+        }
+    }
+
+    fn get_instance_internal() -> Arc<Self> {
         use std::sync::OnceLock;
         static INSTANCE: OnceLock<Arc<TritonVmJobQueue>> = OnceLock::new();
         INSTANCE