synth-bm: include it in the root workspace

[mooori]

Closes #12887

[mooori]

By using a different name, it's possible to add near-jsonrpc-client from crates.io to the workspace dependencies. I think that's a slight improvement because it:

• reduces the number of dependencies that cannot be inherited from the workspace
• makes it more explicit that there are two different near-jsonrpc-client crates

[Longarithm]

Looks like the amount of version conflicts make it not worth it, then using local near-jsonrpc-client is a better first step.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.

Project coverage is 70.29%. Comparing base (fb95d7b) to head (8fa037e).

Files with missing lines	Patch %	Lines
benchmarks/synth-bm/src/account.rs	0.00%	3 Missing ⚠️
benchmarks/synth-bm/src/contract.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #12901       +/-   ##
===========================================
+ Coverage    1.73%   70.29%   +68.56%     
===========================================
  Files         675      857      +182     
  Lines      121457   175449    +53992     
  Branches   121457   175449    +53992     
===========================================
+ Hits         2108   123335   +121227     
+ Misses     119246    46990    -72256     
- Partials      103     5124     +5021     

Flag	Coverage Δ
backward-compatibility	0.36% <ø> (?)
db-migration	0.36% <ø> (ø)
genesis-check	1.42% <ø> (ø)
linux	70.15% <0.00%> (+68.41%)	⬆️
linux-nightly	69.95% <0.00%> (?)
pytests	1.73% <ø> (ø)
sanity-checks	1.54% <ø> (ø)
unittests	70.13% <0.00%> (?)
upgradability	0.36% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mooori]

For cargo deny to pass, I had to add a bunch of crates to skip in deny.toml. @nagisa could you have a look if this is handled properly? Since I haven't touched nearcore's deny.toml before...

[nagisa]

You shouldn't allow local crates at all. The order of priority is to allow the older external crates, then the external crate.

[Longarithm]

It'd be nice to have short comments on what's our main goal to use deny.toml. It took me a while to understand. Looks like the goal is "restrict using duplicate versions + deny some specific versions + allow multiple versions where it's unavoidable" and meaning of keywords "deny" and "skip" isn't obvious here.

[nagisa]

I don't believe "restrict using duplicate versions" is a goal: we never really pushed much against adding to the list of exceptions here. In fact we would have much harder time maintaining protocol compatibility if we couldn't duplicate our dependencies.

However what our use of deny.toml does okay is nudging us to update our dependencies once in a while when pulling in an external dependency inevitably duplicates some transient dependencies that don't pose a risk on our protocol compatibility. Exactly as seen with some of the dependencies below.

Now, since I wasn't the one to introduce cargo deny, I can only guess what the original intention was, but I'm about 90% sure it was somewhere along the lines of "eh, why not…" rather than something profound. And whatever benefit that gets derived from the tool is fairly subjective between maintainers of this repo :)

[nagisa]

Try updating the crates to unify the dependencies before allowing them. I don't see any reason why we shouldn't be bumping our base64 or http related crates and situations like these are a perfect opportunity.