Test Local Driver

[willbeason]

The local driver has problems when trying to handle large numbers of templates.

Below is a performance test (included in this PR) which measures how long it takes to add N templates to the driver.

BenchmarkDriver_PutModule/1_templates-12         	    2696	    469,513 ns/op
BenchmarkDriver_PutModule/2_templates-12         	    1064	   1,124,514 ns/op
BenchmarkDriver_PutModule/5_templates-12         	     357	   3,530,500 ns/op
BenchmarkDriver_PutModule/10_templates-12        	     100	  10,047,225 ns/op
BenchmarkDriver_PutModule/20_templates-12        	      46	  31,473,562 ns/op
BenchmarkDriver_PutModule/50_templates-12        	       7	 159,611,378 ns/op
BenchmarkDriver_PutModule/100_templates-12       	       2	 720,247,533 ns/op

Note that performance is approximately n^2. This is due to the fact that:

1. Compilation time for a rego runtime environment is proportional to the number of templates.
2. We recompile for each template added.

A few PRs from now, I'm going to make a relatively complex change to try to resolve this issue. Our current tests are good at testing happy paths, but it's very possible I'll trigger changes to unhappy paths, and I want to be able to make those changes safely.

Thus, this PR adds a lot of unit tests for the local driver. There is overlap between local_test.go and local_unit_test.go but the two files are approaching the tests from different directions. The former mainly tests happy-path behaviors in sequences of calls, and local_unit_test.go strictly tests single operations, and as many paths as feasible to unit test.

To aid in testing and discovery I've moved local.Args to its own file, and defined a few new args to aid in writing tests. I've made a few small refactorings (e.g. extracting out the externalDataImpl function), but nothing that changes the overall flow of the code. Similarly, I've moved around how we instantiate the local.driver so testing is cleaner.

Other than that. I've avoided making logic changes except where it was very clear that the code was having an unintentional effect (such as continuing to process after an error state has been reached).

[codecov-commenter]

Codecov Report

Merging #145 (243b26b) into master (f478d8a) will increase coverage by 1.82%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #145      +/-   ##
==========================================
+ Coverage   42.15%   43.97%   +1.82%     
==========================================
  Files          55       56       +1     
  Lines        3117     3131      +14     
==========================================
+ Hits         1314     1377      +63     
+ Misses       1409     1379      -30     
+ Partials      394      375      -19     

Flag	Coverage Δ
unittests	43.97% <ø> (+1.82%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...-agent/frameworks/constraint/pkg/client/backend.go	68.75% <0.00%> (ø)
...eworks/constraint/pkg/client/drivers/local/args.go	93.75% <0.00%> (ø)
...works/constraint/pkg/client/drivers/local/local.go	68.10% <0.00%> (+18.10%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f478d8a...243b26b. Read the comment docs.

[maxsmythe]

LGTM

[maxsmythe]

though it looks like there are failing tests