cargo-credential-libsecret: load libsecret only once

[biglben]

Previously, libsecret was repeatedly loaded and unloaded—at least twice during cargo login (once for action get and once for action login). This caused issues where calls could hang indefinitely due to glib failing to clean up properly (some threads still running after unloading) and generating numerous error messages:

cargo login --registry ownreg
    Updating `ownreg` index
please paste the token for ownreg below


(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot register existing type 'SecretService'

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot add private field to invalid (non-instantiatable) type '<invalid>'

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: cannot register existing type 'SecretBackend'

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:100727): GLib-CRITICAL **: 08:59:54.568: g_once_init_leave_pointer: assertion 'result != 0' failed

(process:100727): GLib-GObject-CRITICAL **: 08:59:54.568: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

Now, libsecret is stored in a OnceLock, ensuring it is only loaded once, preventing unnecessary unload/reload cycles.

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

The main thing I'm wondering is if this is the right layer of caching.

Alternatively, we could lazy load these fields in LibSecretCredential and use a OnceLock on that in the cargo side of the code. Or we could skip OnceLock and have a cache on GlobalContext which would give users control over lifetimes.

A potential way to side step any of that is for us to not load the library multiple times. It looks like during login() we call registry() to get Registry::new_handle() so we can call registry.host() . We might be able to split registry() into registry() and registry_cfg() and use the latter in login(), avoiding looking up the token just to throw it away.