Move the database backend selection from the `dev` config file into the
main `Config` struct, i.e. into production.
This will enable an sql database backend to be used in production.
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 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.
