[store] Rename datastore to sqlstore

[the-glu]

This is a series of PRs, aiming to fix #1418 with better organization of datastore interfaces.

PRs are chained, and composed of the following:

#1444 : Merge datastore.Store and datastore.Datastore
#1445 : Move initialization into clean datastore.Store interface and use generic stores
#1446 : Rename datastore to sqlstore
#1447 : Move 'CodeRetryable' to generic store package
#1448 : Add 'store_type' flag
#1449 : Show example of new datastore type (not to be merged, demo only).

---

This PR just renames 'datastore' instances to 'sqlstore', making it more explicit that it's using a SQL implementation and removing confusion with store/datastore both being generic.

Flags haven't been renamed yet, waiting for confirmation.

We could have also renamed it to PostgresStore, which would also be valid.

[BenjaminPelletier]

I do think names are important so it's worthwhile to make sure we pick the best one possible at the time. I'm fine with either sqlstore or PostgresStore, but I would consider those two different design decisions. Naming "sqlstore" would suggest that if we were ever to support a non-Postgres database, that functionality would be added to sqlstore. Naming "PostgresStore" would suggest that the non-Postgres database support would be added to a separate object and PostgresStore wouldn't be affected. So, if we (hypothetically) wanted to support MariaDB, would that support go in this object (implying "sqlstore" is the better name) or in a different object (implying "PostgresStore" is the better name)?

[the-glu]

I do think names are important so it's worthwhile to make sure we pick the best one possible at the time. I'm fine with either sqlstore or PostgresStore, but I would consider those two different design decisions. Naming "sqlstore" would suggest that if we were ever to support a non-Postgres database, that functionality would be added to sqlstore. Naming "PostgresStore" would suggest that the non-Postgres database support would be added to a separate object and PostgresStore wouldn't be affected. So, if we (hypothetically) wanted to support MariaDB, would that support go in this object (implying "sqlstore" is the better name) or in a different object (implying "PostgresStore" is the better name)?

MariaDB, with its specific connection would probably go into a separate object by default.
However: we could want to a generic sql.DB pointer instead of a *pgxpool.Pool internally, and use the already-existing Version.Type to make different queries for non-postgres-sql-dialect queries. I didn't explicitly tested it, but interface look compatible with the generic one.*
Also the generic dsssql.Queryable is still used in repo's specific-implementations, making them 'connection'-agnostic.

* Should that be a follow up PR ?

[BenjaminPelletier]

I do think names are important so it's worthwhile to make sure we pick the best one possible at the time. I'm fine with either sqlstore or PostgresStore, but I would consider those two different design decisions. Naming "sqlstore" would suggest that if we were ever to support a non-Postgres database, that functionality would be added to sqlstore. Naming "PostgresStore" would suggest that the non-Postgres database support would be added to a separate object and PostgresStore wouldn't be affected. So, if we (hypothetically) wanted to support MariaDB, would that support go in this object (implying "sqlstore" is the better name) or in a different object (implying "PostgresStore" is the better name)?

MariaDB, with its specific connection would probably go into a separate object by default. However: we could want to a generic sql.DB pointer instead of a *pgxpool.Pool internally, and use the already-existing Version.Type to make different queries for non-postgres-sql-dialect queries. I didn't explicitly tested it, but interface look compatible with the generic one.* Also the generic dsssql.Queryable is still used in repo's specific-implementations, making them 'connection'-agnostic.

• Should that be a follow up PR ?

I don't think we actually need to do any of the abstraction/generification unless it's actually needed at some point, I just want to make sure our incremental changes (renaming of datastore in this PR) are pointed in the right direction. So, if we would put MariaDB into a separate object, I'd recommend PostgresStore. If we would make a generic sql.DB pointer to use instead of pgxpool.Pool, then sqlstore sounds appropriate. There's always the possibility we'll make the wrong choice now when we have hindsight later, but that's fine too -- I just think it's worth trying to make our best guess with what we know now.