Consider using rust+cargo for some external libraries

[wraitii]

This ticket to try and answer the following question:

Should we consider using external rust libraries instead of external C++ libraries, with a simple conversion layer. Consider a ticket like #4710, which suggests using OS keyrings for password storage. This is a good idea, and we could find a C++ library, but:

• we'd need to compile it on mac os / make sure it's available across linux + windows
• we'd need to make sure it's up-to-date and reasonably safe.
• it's still an external library with some likelihood of a C-like interface anyways.

If instead we exposed rust bindings, we could:

• leverage cargo, which would make the experience pretty easy
• be slightly more comfortable with its safety, at least memory wise.
• the ecosystem happens to be pretty active as well, so libraries might be newer overall (see fcollada)
• we'd probably want a wrapper layer anyways.

We'd have some setup pains for sure, but in the long term I can see that replacing a number of our external libraries:

• gloox seems like a candidate for replacement, though we're integrating somewhat tightly with it.
• tinygettext / iconv
• ICU?
• libsodium
• stuff like miniupnpc
• fcollada

All of the libraries that we use in only a few files and at a few distinct points are good candidates IMO, and that's most of them.

[Vladislav Belov]

From the initial discussion:

we'd need to compile it on mac os / make sure it's available across linux + windows

It's the same for Rust. Plus Rust might have breaking changes across versions which is not happening for C.

we'd need to make sure it's up-to-date and reasonably safe.

It's the same for Rust. It'll be using a low-level C library anyway with it's own bugs (like gnutls).

leverage cargo, which would make the experience pretty easy

Cargo is much nicer definitely.

be slightly more comfortable with its safety, at least memory wise.

I'd say this "slightly" mostly invisible in terms of safety for our case.

the ecosystem happens to be pretty active as well, so libraries might be newer overall

It might also mean that it can be stopped developing with replacing by another library with incompatible changes.

we'd probably want a wrapper layer anyways.

I experience up to 50% performance loss on high-load applications with Rust. So we need to consider/check it as well. Also it needs to check how wrappers deal with memory ownership, we don't want to have unnecessary copies.

fcollada

I think it's better to replace it by glTF (or any other modern library).

[Stan]

Push back