Being stuck on Rust 1.61.0 is unacceptable about plrust

[workingjubilee]

12. It's becoming really hard to avoid using more recent features unintentionally while improving the unsafe code in pgx, because a lot of the work that has been done to make our pointer abstractions better has been entirely recent. And by "recent", I mean "it was stabilized 6 months ago". While working to make pgx::datum::Array<'a, T> safer, more correct, and eventually faster, I accidentally used a library feature stabilized in Rust 1.63¹, to which I say: lmao.
13. Our test framework was improved using a const fn stabilization in Rust 1.63, that's pgcentralfoundation/pgrx#833, which uses Mutex::new() becoming stable in const fn to avoid having to use a Lazy (from another dependency! once_cell) just to initialize with Mutex::new(Vec::new()) (which is just a Mutex around a nullptr and two 0s).
14. In order to circumvent these two recent issues, I have pinned the dependencies for building PL/Rust, which is considered by many esteemed maintainers to be a security malpractice. This is exacerbated in Rust as Rust's usage of static linking inhibits simply replacing the underlying components, thus the only way to assure things build with security issues resolved is to keep moving support forward. The way we are using a rust-toolchain.toml is also, effectively, pinning dependencies.

Footnotes

1. Per the tracking issue for #![feature(slice_ptr_len)], it's almost impossible to get the len of a pointer to a slice correctly without NonNull<[T]>::len() so I didn't have many options here. ↩