feat: support dual mode data storage

[jrconlin]

Allow for dual mode, where data is written to the primary, but the
secondary is read in order to 'back fill'. For simplicity, Dual presumes
that the primary data store is Bigtable and the secondary is DynamoDb.

This presumes that the db_settings contains serialized settings for
both data stores.

Closes: SYNC-3452

Blocks on #364

[pjenvey]

I don't think this client feature is being used anywhere?

Suggested change

	sentry-core = { version = "0.31", default-features = false, features = [
	"client",
	] }
	sentry-core = { version = "0.31" }

[jrconlin]

I do wonder if i should audit the libraries and features we're pulling in. I know there's a cargo feature that allows for that, but it needs nightly...

[pjenvey]

Suggested change

	#[derive(Clone, Debug, Default, Deserialize)]
	pub struct DualDbSettings {
	#[serde(default)]
	primary: DbSettings,
	#[serde(default)]
	secondary: DbSettings,
	#[serde(default = "set_true")]
	write_to_secondary: bool,
	}
	fn set_true() -> bool {
	true
	}
	#[derive(Clone, Debug, Deserialize)]
	pub struct DualDbSettings {
	primary: DbSettings,
	secondary: DbSettings,
	write_to_secondary: bool,
	}

[jrconlin]

Fair, I had originally wanted to do these as optional and resortable, but that's not happened.

[pjenvey]

Why not check secondary?

[jrconlin]

I was debating that.
I wanted the call to be reasonably fast and working through the logic around which sources to poll might be weird. Plus, since we don't pass the UAID, we're kinda arbitrarily picking which data store to read from anyway.

Picking just primary ensures that the prime database is correct, with the secondary being just that, and lesser priority. (Honestly, once we're on bigtable, we could drop this entirely, but there's probably good reasons to keep it in case we ever have to move to another data store).