BTree: keep values off the function call stack while inserting

[ssomers]

VacantEntry::insert receives a value and returns a reference to the value's final location. Internally, it passes the value several levels down the stack, sneaks back a pointer to the place where the value was written, and converts that pointer to a reference at the last minute. I think it's actually safer and more efficient to not pass the value around, but only the location, and write the value there at the last minute.

• Safer because every use of VacantEntry::insert (including your average BTreeMap::insert) ensures the correct address is returned, whereas now there is only one unit test (in test_entry) superficially testing that the returned reference really points to the value.
• More efficient because we don't need to move the value down the stack (as witnessed in Large BTreeMap key or value types cause avoidable stack overflow #81444), in case that's representative for something that matters.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[bors]

☔ The latest upstream changes (presumably #98091) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #98178) made this pull request unmergeable. Please resolve the merge conflicts.