Supporting cargo binstall?

[workingjubilee]

At least one user mentioned they like to use cargo binstall, and it seems sensible enough, but that user also encountered mysterious problems when updating a project which leads me to suspect we may need to tweak some details in our Cargo.toml metadata in order to fully support binstalls.

PGRX and thus cargo pgrx has some security concerns given the nature of the projects it builds, but our CI is secure enough that cargo binstall piggybacking off of it seems like a fine way of delivering a binary for common devtool usage. High-security operations which trust other networks less will want to build from our Rust source after obtaining a trusted Rust compiler, naturally, but our README and the like is effectively talking to the average user who hasn't brought in any other considerations yet, which includes a lot of Jackie Devvers.

But, honestly, given that our next action is to recommend the user fetch and build from source all versions of Postgres that we support, uh... well, the "resource constrained devices" reasoning for supporting binstalls doesn't apply as much.

Important detail: We would also like our users to use the lockfile we actually checked in, so we would want that to also be done by the binstall build. If that can be arranged, that itself is actually a reason to support them.

[workingjubilee]

Okay, I don't think this is actually viable given issues in cargo-pgx mentioned in #687. We might be able to fix that so cargo-pgx is independent eventually, but not today.

[usamoi]

Will we reopen this issue since we have removed dlopen?