The upcoming kvdb to sql code migration will be added to as part of the
`sqldb/v2` migration stream. However, since the kvdb to sql migration
will need to use the migration functions present in the `accounts`,
`firewalldb`, and `session` packages, the migration will need to
referernce those packages. That would lead to a circular dependency
though if the migration stream was defined in the `db` package, as those
packages need to import the `db` package.
To avoid this, we introduce a new `migstreams` package that
contains the migration streams, and ensure that the `db` package doesn't
import the `migstreams` package.
- Replace occurrences of `// nolint:lll` with `// nolint:ll` across
files for consistency.
- Reformat multiline strings, comments, and function parameters to
improve clarity and adhere to style guidelines.
- Add `// nolint:ll` comments where necessary to prevent linter
warnings.
In this commit, we do our best to ensure that at least at the time of
action creation, if the account ID is set, then our bbolt actions store
impl will at least first check that the account really does exist. This
also forces us to update our tests in preparation for the SQL store
which will tightly couple the actions and accounts.
In preparation for using the clock to get an Action's AttemptedAt time
in an upcoming commit, we let both the bbolt and SQL impls of the
firewalldb take a clock.
In this commit, we add a `DB` struct in the `firewalldb` package. This
struct will be responsible for housing abstract implementations of the
various stores in the `firewalldb`. For now, we start with just the
RulesDB. We also add Start&Stop methods for the struct in preparation
for future additions here - for now, these do nothing.
In the main LiT setup, we move the firewall.BoltDB and the new
firewalldb.DB to the `stores` struct and implement them in the two
`config_` files. For now, both varients create the Bbolt version of the
firewallDB and this is used to init the `firewalldb.DB` struct. This
will be changed in future commits where we will add a sql
implementation.
In this commit, we expand the dev build's DevConfig options struct with
Postgres and SQL backend options that can be used to initialise the
account store.
In this commit, we introduce a DevConfig struct which is embedded in the
main lit Config struct. It is defined in two separate files that are
made mutually exclusive using the `dev` build tag. The idea of this
struct is that it allows us to expose additional config options to LiT
if we build in a development environment such as our itests. In other
words, we will be able to start developing features and testing them
before making them available to users via the production build.
As of this commit, both implementations of the struct are the same.
