Filter: load JSON definitions and policies from file

[robobario]

Why:
We want users to have access to the full Smorgasbord of configuration including different encryption policies per-topic and support for multiple KMS implementations.

With this change the Kroxylicious Filter will require configuration to point to the two JSON files. This gives us the closest integration with the encryption module because JsonPolicyLoader.loadTopicPolicies works in terms of File objects and does some useful work like validating and associating policies and KMS implementations.

example Kroxylicious configuration

filters:
  - type: TopicEncryption::EncryptProduce
    config:
       inMemoryPolicyRepository:
         kmsDefinitionsFile: "/path/to/kms-def.json"
         topicPoliciesFile: "/path/to/topic-policies.json"
  - type: TopicEncryption::DecryptFetch
    config:
       inMemoryPolicyRepository:
         kmsDefinitionsFile: "/path/to/kms-def.json"
         topicPoliciesFile: "/path/to/topic-policies.json"

In future, if we want to be able to embed the KMS definitions and topic policies in the Filter configuration it might be nice if JsonPolicyLoader had another method like:
List<TopicPolicy> loadTopicPolicies(List<TopicPolicy> topicPolicies, Map<String, KmsDefinition> kmsDefs) that did the same work without the dependency on loading JSON from File.

Implements #3

[robobario]

I've now refactored the tests, splitting them into tests covering Produce Encryption and Fetch Decryption, testing each side in isolation. This combined with adding tests for per-topic encryption policies would catch the issues fixed by commit #de60abe. The tests were working because of the hardcoded wildcard policy combined with the metadata request failure caching an empty string. We found a name for the topic (empty string), and that got the wildcard policy applied to it, test passes ✔️

[robobario]

To catch a comment from the demos, @SamBarker pointed out that it would be good if we could get credentials into the key manager definition file (like the vault token) in a kubernetes friendly way. So instead of directly in our JSON file, refer to a secret file or environment variable. Captured in #8

[SamBarker]

A few cosmetic thoughts but looks good to me.