cargo: enable LTO for release builds

[csssuf]

LTO makes the final binary a bit smaller, and isn't really a risk here,
so enable it.

[cgwalters]

Relatedly, just my 2¢ - in rpm-ostree we do:

[profile.release]
panic = "abort"
lto = true

As I think for binaries (and particularly daemons managed by systemd) you really want a core dump collected. panic=abort definitely makes things faster as lots of conditional branches get elided. Edit: more information.

[sdemos]

what's the size difference with the binary now with panic=abort?

[csssuf]

> $ ls -lh target/release/coreos-metadata*
-rwxr-xr-x 2 james james 3.4M Jul 23 14:30 target/release/coreos-metadata
-rwxr-xr-x 2 james james 3.0M Jul 23 14:02 target/release/coreos-metadata-abort

[lucab]

I'm wary of switching the panic behavior to abort. It will get in the way of any library we consume trying to catch its own panic, and it will also prevent any destructor to properly run (think of lockfile and other steps to undo).

The rpm-ostree is a different case and that setting makes sense there, as that one is a staticlib consumed by C and unwinding through FFI is not supported.

[cgwalters]

think of lockfile

Lock files are cleaned up by the kernel.

[sdemos]

update-ssh-keys also relies on the destructor being run to switch back to the original user after calling setuid and setgid to write the ssh keys. that seems like something that might also get cleaned up by the os though? I'm not sure.

[csssuf]

Since it seems like we're not sure if we want panic = abort, I'll just revert back to only enabling LTO in this PR and we can turn on panic = abort in a followup if we decide we do want it.

[cgwalters]

update-ssh-keys also relies on the destructor being run to switch back to the original user after calling setuid and setgid to write the ssh keys. that seems like something that might also get cleaned up by the os though? I'm not sure.

Yeah, calling setuid only affects the current process; if the entire process goes away there's nothing to clean up.

[cgwalters]

It's probably worth mentioning a case that isn't handled with simple process death: rust-lang/rust#49032 (comment)

(Though IMO here the fix is a kernel API to say that the tty mode changes made by a process should be transient; a userspace workaround would be to fork off a helper process whose sole job is to monitor the parent process and reset the tty mode on exit)

[csssuf]

I've opened #107 to track panic=abort; since LTO seems agreed-upon I'll merge this as-is.