switch jemalloc-sys back to tikv-jemalloc-sys, and update to 0.6.0

[lqd]

Some context:

• we used to use jemalloc bindings from https://github.com/gnzlbg/jemallocator, since Remove the alloc_jemalloc crate #55238
• that crate was abandoned, picked up as a fork in https://github.com/tikv/jemallocator, so we switched to that in Use tikv-jemallocator in rustc/rustdoc in addition to jemalloc-sys when enabled. #83152.
• then they were able to publish to the original jemalloc-sys bindings crate, and jemalloc-sys and tikv-jemalloc-sys became the same thing -- so I switched back to the OG crate in Update jemalloc to v5.3 #96790
• they're now having publishing problems again: I've been waiting for Bump jemalloc 0.6.0 tikv/jemallocator#96 for the jemalloc-sys 0.6.0 update for a few months, but tikv-jemalloc-sys is already updated to 0.6.0.

A perf run showed some improvements: jemalloc enables stats reporting by default and version 0.6.0 of the bindings now correctly enables/disables this setting when compiling the library depending on the stats cargo feature actually being activated. So, this PR switches back to tikv-jemalloc-sys to update to 0.6.0.

[lqd]

@bors try @rust-timer queue

[bors]

⌛ Trying commit a69fe84 with merge c4063b417f80744aa7e0f240e2c7be86d706c158...

[bors]

☀️ Try build successful - checks-actions
Build commit: c4063b4 (c4063b417f80744aa7e0f240e2c7be86d706c158)

[rust-timer]

Finished benchmarking commit (c4063b4): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.3%, -0.1%]	77
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.1%]	31
All ❌✅ (primary)	-0.2%	[-0.3%, -0.1%]	77

Max RSS (memory usage)

Results (primary -1.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.6%	[-1.6%, -1.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.6%	[-1.6%, -1.6%]	1

Cycles

Results (primary 1.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.9%	[0.9%, 2.5%]	7
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.9%	[0.9%, 2.5%]	7

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 767.333s -> 766.603s (-0.10%)
Artifact size: 332.08 MiB -> 330.99 MiB (-0.33%)

[Mark-Simulacrum]

r=me

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[lqd]

@bors r=Mark-Simulacrum

[bors]

📌 Commit a69fe84 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit a69fe84 with merge 490b2cc...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 490b2cc to master...