Enable all SQLite extensions that do not require code changes.

[TheOneTheOnlyJJ]

What is the problem this feature will solve?

SQLite has a few compile-time extensions that are not enabled by default in Node.js, meaning developers cannot use them out of the box.

Inspired by #56447, I suggest enabling all SQLite extensions that do not require additional code written by default (just as the math functions from #56447). We should target the entire SQLite amalgamation and all the other default extensions (again, such as the math functions from #56447).

Potential candidates include:

• Full Text Search 5, with -DSQLITE_ENABLE_FTS5.
• Full Text Search 3, with -DSQLITE_ENABLE_FTS3 and -DSQLITE_ENABLE_FTS3_PARENTHESIS.
• R*Tree Module, with -DSQLITE_ENABLE_RTREE.
• DBSTAT Virtual Table, with -DSQLITE_ENABLE_DBSTAT_VTAB.
• The RBU Extension, with -DSQLITE_ENABLE_RBU.

Unless there are explicit reasons why these should not be included, I see no reason to withhold them from developers.

What is the feature you are proposing to solve the problem?

Add the extensions' compile-time extension flags to Node.

What alternatives have you considered?

Compiling and linking your build of SQLite with the extensions enabled is a major hassle for developers and users alike.

[geeksilva97]

Would you have any objection, @cjihrig?

(I'm about to mention better-sqlite3 again 😅 ) better-sqlite has some of these

[TheOneTheOnlyJJ]

After taking another look at this, I noticed that the RBU extension is not fit to be added. However, from the list you shared here, I now see even more viable extensions that I didn't know existed until now (like geopoly).
Adding these flags would increase the build size, but other than that, we would get more SQLite features with no other effort involved.

[cjihrig]

Would you have any objection, @cjihrig?

No objection, but I think we should evaluate each one of these individually. We need to weigh features against any impact on performance and/or binary size.

[TheOneTheOnlyJJ]

I'm very busy at this time and cannot contribute, but what are the steps required to do this properly?

Do tests have to be written?

No objection, but I think we should evaluate each one of these individually. We need to weigh features against any impact on performance and/or binary size.

How would this impact be effectively measured?

I'm interested in the perspectives being considered when deciding on each extension.

[cjihrig]

Do tests have to be written?

If new functionality is enabled, there should be at least one test to prevent regressions.

How would this impact be effectively measured?

For #56541 I wrote a script and compared the execution time with and without the change. To evaluate the binary size, you can look at the file size of the node binary.