Put bundled steamworks sdk behind feature

[tbillington]

The bundling of the steamworks dynamic libraries with releases is very convenient, however it should be possible to opt-out if the user so chooses.

My suggestion would be a bundled feature that is on by default, but could be disabled through the use of "no default features" in Cargo.toml.

Reasons users may opt-out

Supply chain best practice

There's no "easy" way to verify the library files are the originals from Valve. Made especially difficult because they are not included in the repository, understandably.

Users should be able to provide the libraries themselves for full certainty they're legitimate.

Patch updates without relying on bevy_steamworks

Users can update the steamworks dynamic libs if they're semver compliant on their own without requiring an upstream patch by bevy_steamworks.

---

Prior art in bundling binary libraries: Rusqlite (sqlite).

[tbillington]

Another option, though I don't know how preferable this is, is either a build.rs step or shell script in the repo that would fetch from the official steamworks servers eg (https://partner.steamgames.com/downloads/steamworks_sdk_159.zip) and unpack the libraries locally.

That could be a separate feature ("download_sdk"?) that users could use in addition to disabling "bundled" to automate the process of acquiring the steamworks sdk.

[james7132]

This is probably something worth filing an issue with steamworks-rs. This crate/repo is merely an integration between it and Bevy.

With that said, steamworks-sys uses bindgen, which adds additional build requirements (i.e. Clang) to building new bindings from scratch, and those bindings may or may not be compatible with the version of steamworks if Valve makes any breaking changes.

[tbillington]

Makes sense, I've opened an issue upstream Noxime/steamworks-rs#160.

[james7132]

If or when the feature is upstream, we'll mirror it in this integration crate. Closing this out for now.