re-architect authz-service

[susanev]

Overview

authz-service has grown into a fuzzy thing that becomes harder to understand with every kludge we add.

Examples

• the service constructors are difficult to instantiate – leading to manual instantiations, and copied-around, diverging interceptor setups: server/v2/project_test.go, server/v2/policy_test.go
• the version of IAM used is known to the main server struct, but its components aren't aware of this, leading to a multiple ways of threading through the IAM version (for example, the authz v2 grpc handler has a way of knowing which version is used through the versionswitch construct, which allows the authz grpc handler to be used as interceptor; the method for updating the engine store is different; the internal v2 and v2.1 GRPC endpoints are the same, so that component just doesn't care) – we should find a way to make all this simple and stupid.
• as a side-effect of this, the opa engine exposes quite odd methods, which almost all do the same thing (with a recent PR, it's mostly 3 variants of each of SetPolicies, IsAuthorized, and Introspection)

Acceptance Criteria

• There are no GRPC middleware setup in any of the test files – it’s an internal concern of the service constructor that they’re using.
• The IAM version used is represented in the service state – the “version switch” interceptor is reading it from there, and nothing is reading the version switch’s Version field.
• There’s no goroutine+channel construct used anywhere to bypass any odd “who knows about what” issues.

Subtasks

• remove goroutine+channel handling version changes and instead the service state always knows the version
• decide and document the shape of the tests we want for all levels of testing (unit, property, integration at service level, integration at app level)
• use service constructors in tests
• refactor OPA methods to be more clear and DRY
• break up giant postgres files and refactor where possible

[susanev]

this work has been deprioritized, so closing.