Decide on if #[global_allocator] should remain in evm_arithmetization

[BGluth]

Recently due to adding SMT support in #198, we need to link against two versions of evm_artithmetization in a single build. This works, except that evm_artithmetization defines a global allocator (jemalloc) with #[global_allocator]. #[global_allocator] can only appear once in any given build, so this ends up breaking compilation.

It seems that best practices are to avoid using #[global_allocator] in libraries and only use it in binaries (since it affects the entire binary, including deps). Currently if there is another binary (or library for that matter) that also defines it's own global allocator, it would not be able to use evm_artithmetization.

My thoughts are we should either do one of the following:

• Remove jemalloc from evm_artithmetization and make this the responsibility of the binary to do this.
• Only enable jemalloc with the presence/absence of a feature flag (this is what Added a feature flag to disable jemalloc #204 does).

Also note that @nbgl mentioned that she is not sure how much performance jemalloc is actually giving us at this point and it might be worth revisiting.

[muursh]

Remove jemalloc from evm_artithmetization and make this the responsibility of the binary to do this.

I'm still a proponent of this

[BGluth]

Also going to add that this issue is much less urgent at this point since we're now back to feature gating SMT support.

[0xaatif]

• fix: only executables should choose a global allocator #301

[0xaatif]

Closing as completed, with follow up in #302