Fix: Lazily evaluate acceptedPublicKeys

If the `acceptedPublicKeys` val is evaluated eagerly within the
`Verification` trait then the `activePublicKey` and `alsoAccepted` vals
won't have been initialised yet from the class which extends the trait.

This was leading to `acceptedPublicKeys` evaluating to 'null' at
runtime.

The added test was failing with the pre-existing code with a very
similar message to the one observed in CODE, so we have some
confidence that it's testing for this case effectively.

See: https://docs.scala-lang.org/tutorials/FAQ/initialization-order.html

Co-authored-by: Roberto Tyley <52038+rtyley@users.noreply.github.com>

pan-domain-auth-verification/src/main/scala/com/gu/pandomainauth/service/CryptoConf.scala

@@ -21,7 +21,7 @@ object CryptoConf {
     val activePublicKey: PublicKey
     val alsoAccepted: Seq[PublicKey]
 
-    val acceptedPublicKeys: LazyList[PublicKey] = LazyList(activePublicKey) ++ alsoAccepted
+    lazy val acceptedPublicKeys: LazyList[PublicKey] = LazyList(activePublicKey) ++ alsoAccepted
 
     private[CryptoConf] def acceptsActiveKeyFrom(other: Verification): Boolean = acceptedPublicKeys.contains(other.activePublicKey)
 

pan-domain-auth-verification/src/test/scala/com/gu/pandomainauth/CryptoConfTest.scala

@@ -18,6 +18,8 @@ class CryptoConfTest extends AnyFreeSpec with Matchers with EitherValues {
       val rotationUpcomingConf = loadExample("1.rotation-upcoming")
       rotationUpcomingConf.activeKeyPair should === (legacyConf.activeKeyPair)
       rotationUpcomingConf.alsoAccepted should not be empty
+      val expectedAcceptedPublicKeys = rotationUpcomingConf.activeKeyPair.publicKey +: rotationUpcomingConf.alsoAccepted
+      rotationUpcomingConf.acceptedPublicKeys should === (expectedAcceptedPublicKeys)
 
       val rotationInProgressConf = loadExample("2.rotation-in-progress")
       rotationInProgressConf.activeKeyPair should !== (legacyConf.activeKeyPair)