#45 have a set of keys instead of just one

[TheLydonKing]

Release Notes:

• Made the Previously rotated public keys available for clients to fetch and allows for clients to parse JWT's that haven't expired but are using an older keyset.

closes #45

[github-actions]

JaCoCo code coverage report - scala:2.12.17

File	Coverage [67.77%]	❌
InMemoryKeyConfig.scala	100%	🍏
PublicKeySet.scala	100%	🍏
PublicKey.scala	100%	🍏
SecurityConfig.scala	85.45%	🍏
TokenController.scala	84.15%	🍏
JWTService.scala	83.28%	🍏
KeyConfig.scala	82.07%	🍏
AwsSecretsManagerKeyConfig.scala	42.39%	❌
ServiceAccountConfig.scala	37.57%	❌
AwsSecretsUtils.scala	0%	❌
AwsSecret.scala	0%	❌

Total Project Coverage	63.58%	🍏

[dk1844]

• I am wondering if it makes sense to distinguish current and old publicKey for the clients -- whether just not give them a set/list (then we can be generic of what we give them in the future and they just have to trust the public keys as a set -- one of them should be the signing one).
  -> so I would rather keep the PublicKey class intact for the current endpoint and created a new class PublicKeySet that would serve the new purpose.

• I don't see the functionality where the previous publicKey is phased out after some time has passed after the rotation - and I don't see a configuration for these timeouts either

[dk1844]

I think option processing can be done better without calling Option.get e.g. via

      secretsOption.fold(
        throw new Exception("Error retrieving username and password from from AWS Secrets Manager")
      ){ secrets =>
        (secrets(usernameFieldName), secrets(passwordFieldName))  
      }

or more explicitly via

      secretsOption match {
        case None => throw new Exception("Error retrieving username and password from from AWS Secrets Manager")
        case Some(secrets) =>
          (secrets(usernameFieldName), secrets(passwordFieldName))
      }

[TheLydonKing]

• I am wondering if it makes sense to distinguish current and old publicKey for the clients -- whether just not give them a set/list (then we can be generic of what we give them in the future and they just have to trust the public keys as a set -- one of them should be the signing one).
  -> so I would rather keep the PublicKey class intact for the current endpoint and created a new class PublicKeySet that would serve the new purpose.
• I don't see the functionality where the previous publicKey is phased out after some time has passed after the rotation - and I don't see a configuration for these timeouts either

• Will do on the PublicKeySet
• Ok, I was under the impression that the previous key would be phased out on rotation but I can add another schedule that phases it out after a set time until rotation occurs.

[dk1844]

See the comments, otherwise LGTM 😃

[dk1844]

LGTM