Change audit orchestration and implement latest strategy

[perama-v]

Description

Updates the audit logic. This enables glados-audit to perform multiple audit strategies within the one binary.
The PR includes the logic for the latest strategy and stubs for additional strategies.

Closes #37.

Dependencies

• Depends on Change block_number i64 -> i32 #59.

Overview

Note: Glados-monitor is unaffected. It continues to watch the chain tip of a non-portal node
and push content keys into the glados database.

Multiple audit strategies are defined. Any (or all) may be invoked by spawning a new thread.
Each spawned thread sends audit tasks via a multi-producer single-consumer channel. Task-creating
threads do not alter the glados database.

An audit task is a content key from the the glados database that is expected to be in a portal node. Tasks are created according to different strategies:

• latest implemented
• random stub
• failed stub
• <additional unimplemented strategies may be added later>

A single thread watches the task channel and performs audits on anything received. Audit results
are stored in the glados database by this thread only, and no database locking is therefore required.

When glados-auditis started, all strategies are commenced. Any unimplemented strategy logs a warning.
A flag could later be added to chose a strategy/strategies. E.g.,

• No flag: Use all strategies
• Flag: Use comma-delimited value strategies only.

Changes

• New selection module to handle the different strategies.
• New SelectionStrategy enum

Usage

let strategy = SelectionStrategy::Latest;
tokio::spawn(strategy.select_latest_content_for_audit(tx.clone(), conn.clone()));

Testing

A test database generator is created that can be used for different strategies. See doctests for more.

Checklist

• Add thread spawner for different strategies
• Update latest with correct logic
• Tidy commits
• Add test for latest logic

Not addressed

The following may be completed in a different PR(s).

• Add CLI
• Implement failed strategy
• Implement random strategy

[mrferris]

Looks good!

Only thing I'd change are a few naming suggestions. The main one is that I think the name selection.rs describes what's being done here better than generator.rs.

One suggestion for a future PR is that we include within the audit's DB record which selection strategy it was triggered by.

[perama-v]

One suggestion for a future PR is that we include within the audit's DB record which selection strategy it was triggered by.

See #63

[perama-v]

All suggested changes have been made

[pipermerriam]

can you rebase now that #59 is merged.

[perama-v]

Rebased on master

[pipermerriam]

has conflicts now... probably from the other one I merged.

I'll get this merged and deployed tomorrow if the conflicts can get resolved by then. Thanks again for all the great work.

[perama-v]

Rebase on master done 👍

[perama-v]

Testing of the latest strategy is now included.