Add invariant manager

[andrewjdawson2016]

Potential risks

[yycptt]

nit: Seems like other places are still returning the struct directly, instead of a pointer. Probably make them consistent?

I think returning struct is fine here as the struct itself is not big. Returning a struct will cause the object to be allocated on the heap and increase GC pressure.

[yycptt]

I am confused. To me, if a check is needed before fix, then it's the caller's responsibility to first call Check() and then Fix(). I think putting them together inside Fix() couples the logic and makes the code a little bit inflexible.

[yycptt]

What's this shard package for?

[emrahs]

+1 I think this can live in the invariants package

[yycptt]

returns sorted list of all invariants types that manager will run

[coveralls]

Coverage increased (+0.04%) to 68.457% when pulling 0bc90d7 on andrewjdawson2016:InvariantManager into 55bf6da on uber:master.

[emrahs]

I don't want to overengineer this, but I have a slightly different idea about how we can implement this part about Policies and Manager and wanted to hear what you think about it:

1. Don't limit the manager to a single policy. Make it such that it defaults to running all policies unless a filter says otherwise. We can keep this filter in a config without hard-coding in the application.
2. Define a collection of all policies (maybe we shouldn't call this policy to avoid confusion), which would act like test cases, where each of them consists of an ordered list of Invariants to test a meaningful case end-to-end. Ideally, these policies should never be too long. An invariant should be able to appear in multiple policies. There shouldn't be any order/dependency requirements between policies in the collection.
3. Manager should take a list of policies to include or exclude (the config I mentioned above), and decide to run all Policies one by one, without worrying about their order. As it checks for the invariants in each policy, it can populate a map of invariant types => check results, and use that map to avoid running a given invariant repeatedly across multiple policies. At the end of the iterations, all invariants that are involved in one or more included policies will get executed exactly once.

If we follow the design above, we get the following benefits:

1. Seperation of concerns between invariants-related logic vs. the overall Scanner. Scanner interacts with a single Manager to run the tests, and the only thing it provides is the config that tells which policies should run.
2. More flexibility in the config without adding complexity. Rather than specifying a predefined policy to run, we can precisely tell what policies we want to run (and/or what policies we don't). Since the policies are not ordered or dependent on each other, the config is simple to manage.
3. We avoid running the same invariant repeatedly if it was already covered by an earlier policy, without adding a complex invariant sorting algorithm to the mix.

For the number of invariants & policies you currently have in the PR, my proposal is definitely an overkill. However, if we eventually have a dozen or more invariants that are spread over multiple overlapping policies, it should scale better in terms of maintainability.