Expose Sqlite a safe wrapper of sqlite3_auto_extension

[Sytten]

Hi!

So right now it is not possible with Diesel to register an extension globally (using sqlite3_auto_extension). There was another discussion on exposing the raw pointer directly (#2829), so I am guessing we don't want to do that. It would still be incredibly useful to have a safe API to do it.

Personally, I have started using my fork of sqlite-loadable-rs to do that, works pretty well but it could be safer and easier to use with the power of Diesel for argument parsing. Once we have an API it becomes trivial to build extensions like sqlite-regex that the community can maintain in third-party crates. Ideally we would also expose a couple functions like sqlite3_get_clientdata, sqlite3_set_clientdata, sqlite3_get_auxdata, sqlite3_set_auxdata through a safe interface (aux data is super important for caching the regex for example).

The particularity of sqlite3_auto_extension is that is not dependant on a connection per say, so I am unsure where we would put that code. We likely also need an interface for the plugin init. Happy to pitch in the code once we have figured that out (if you want that in diesel codebase obviously).

[weiznich]

I'm generally open to accept PR's that add safe interfaces of any of the built-in SQLite functions, as long as that does not require adding new feature flags. For extensions there is #2180 which basically stalled because I found no way to detect at build time if the underlying sqlite library was build with extension support enabled or disabled.

[Sytten]

Alright, will see if I can come up with something. This kinda of a new concept since it is a global thing, so maybe free functions with some reuse from the add functions already present on the connection object. I guess we will have the same problem as #2180 since it can fail if the extensions loading is not enabled, but it is probably fine to return a runtime error at that point.

[weiznich]

Returning a runtime error is fine. The problem with #2180 was that we run into linker errors if that function was disabled because than it literally did not exist at all.

[Sytten]

Hum the extension functions usually relies on sqlite3ext.h. So I expect there is really no way but have a feature flag on that one. I know libsqlite3-sys does expose the functions but I would need to check how they deal with that in the linker.