[SIP] sqlite host component

[rylev]

This introduces a SIP for adding a sqlite interface to Spin as well as an initial MVP implementation.

Much like the key-value interface, this would be a "batteries included" implementation where users gain access to a SQL database with no configuration required.

I have also created an example TODO application that uses this MVP implementation.

[rylev]

@itowlson I think this is ready for another look. The implementation pretty much matches the SIP now. That means the open questions still remain, but we have a working prototype. I guess the question now is: should we answer the open questions or merge and then figure out the open questions?

(FYI: the CI failure is because spin-componentize needs to be updated)

[itowlson]

Commented only on the SIP (haven't read through the implementation but can if you want)

[vdice]

Quick proofreading review for the SIP

[rylev]

I am marking this PR as ready to review. While this feature is not complete, I do believe it is useful enough for folks to start experimenting with. Below I've tried to capture the current state and the open questions we need to answer before we can officially make this a stable feature:

This PR provides the following features:

• Support in spin for a sqlite host implementation that provides a default sqlite database when running spin locally.
• Support for runtime configuration for adding additional local sqlite databases.
• Rust SDK support for targeting these databases from a Rust based spin component
• The ability to run arbitrary sql statements against the default database on start up with spin up --sqlite-migration="YOUR SQL HERE"

There are still some open questions and things to discuss/think about:

• I do not believe this feature is ready to marked stable. As such I have put sqlite support behind a feature flag in the only SDK that currently supports it: Rust. This will still allow folks to target sqlite if they create spin components manually (i.e., using wit-bindgen directly), but I believe we already consider such usage experimental and not officially supported by our backwards compatibility guarantees. If we believe that by merging this PR that we are committing to backwards compatibility of this feature in its current form, then I think we should wait and consider how we want to allow for experimentation before committing to backwards compatibility.
• There are still some open questions in the SIP with regards to sqlite versioning and capacity limits. I don't believe those need to be solved before experimentation can begin.
• There is no support for this feature in Fermyon Cloud. Since this is an experimental feature only, I believe that this is fine for now - though we will quickly want to change that.

[itowlson]

Some comments / questions / nits but nothing that can't be iterated on as we build it out. Nice one - thank you!

[itowlson]

By the way, what is the order of landing things for the first iteration? I saw the PR took a dependency on a branch of spin-componentize. Is the idea that we would land spin-componentize first? Is that going to be the general workflow for as long as we need to continue to support modules? (cc @dicej)

[dicej]

Looks great overall.

The async { $BODY }.await stuff is aggravating my OCD, mainly just because $BODY does synchronous I/O and no async, so I'm definitely in favor of using block_in_place instead. No need to split each method, either -- just make it task::block_in_place(|| { $BODY }).

[radu-matei]

LGTM, and the todo example works great for me!

This is really exciting, thanks for working on it, @rylev!

[rylev]

I think this is ready to merge. We'll wait until the next version of spin is released so that we have a full release cycle to let this bake.

[lann]

We could hedge on this by changing the function name to e.g. query-all, reserving query for a future cursor API.

[rylev]

I've addressed this in the latest commit.