Add a `ddbs_options()` for quiet parameter

[Cidree]

It would be nice to silent all functions by default with a ddbs_option.
As you designed the idea of ddbs_options, could you implement that @e-kotov ?

[e-kotov]

@Cidree in https://github.com/e-kotov/sx I designed a three tier system: completely quiet, info (by default) with messages like sf's warnings about creating centroids from latlon data and constant argument assumptions etc, and debug, which shows messages such as "data imported" , "spatial join done" (these messages, I believe, are a bit annoying and pollute the console output, but that's me).

Would you like a similar more extended system in duckspatial and what kind of defaults would you prefer?

For reference, see example of implementation in https://github.com/e-kotov/sx/blob/main/R/sx_options.R

[Cidree]

@e-kotov I like your three tier design with sx, so I think that will be great.
Do we need to rework current cli messages, or do you think it is already compatible with that design?

[Cidree]

About this, I think it will be a good idea to remove the "Query sucessful" from every function that is not creating/overwriting a table, as it doesn't give any value to the user. I think the "Query sucessful" gives some value when we create a new table in DuckDB, as no data is retrieved. But it's useless when data is retrieved. Of course the query was sucessful, as users we see the data.
What do you think?

[e-kotov]

that is not creating/overwriting a table

But what about the views? If we fully transition to 'do everything in duckdb', every function will be creating a view.

[Cidree]

When we create a view after a geospatial operation, it's true that we create a table, but the user gets in return a pointer to the view. However, when we use for instance ddbs_combine(data, conn = conn, name = "data_comb"), we are just executing the query to create the combined table, but we don't retrieve data or a pointer to the data. In that second case, printing a message is useful. In the first case, however, it can become annoying: if a user pipes, let's say, three ddbs_*() functions together, they’ll see “Query successful” printed three times.

[e-kotov]

I would see ddbs_combine(data, conn = conn, name = "data_comb") as a legacy workflow anyway, as with duckdb-centered approach you would do:

data_comb <- ddbs_combine(data)

And data can be either sf or duckspatial_df. And depending on the 'output' (or 'mode' as discussed in #83 or something else), output could also be sf or duckspatial_df or something else.

In any case, I am note sure we really need a confirmation for either views or tables creation, as e.g. we mostly don't get confirmations when manipulating sf objects in sf, or when manipulating tables with 'dplyr' or with 'data.table'. I don't see the point of emitting a message unless there was a problem. So my general assumption would be that if everything went well, just stay silent, no matter what the operation/function was supposed to do. This is why I chose not make all similar messages in sx in debug only most verbose mode.