Replace all test private keys with dynamically-generated keys like //.hierarchy

Twice in the last two weeks we have uploaded new private keys in PRs, and had to have SRE block those keys because they're compromised.

This should be impossible. We should make it so that boulder has no need for checked-in keys, by dynamically generating any such keys when the integration tests start. Then we should enable push protection with secret scanning to ensure that we never upload a private key to this repo ever again.

$ ag -l "BEGIN.*PRIVATE KEY"

• test/test-root2.key
• test/test-root.key
• test/hierarchy/*.key.pem
• test/grpc-creds/*/key.pem
• test/test-ee.key
• test/test-example.key
• test/mail-test-srv/localhost/key.pem
• test/mail-test-srv/minica-key.pem
• test/redis-tls/minica-key.pem
• test/redis-tls/boulder/key.pem
• test/redis-tls/boulder-redis/key.pem
• test/redis-tls/redis/key.pem
• test/wfe-tls/minica-key.pem
• test/wfe-tls/boulder/key.pem
• ca/testdata/ca_key.pem
• ca/testdata/testcsr.go
• cmd/ocsp-responder/testdata/test-ca.key
• grpc/creds/testdata/example.com/key.pem
• wfe2/test/238.key
• wfe2/test/178.key
• wfe2/wfe_test.go

$ find -type f -iname '*.der'

• //test/test-root.key.der
• //test/test-key-5.der
• //test/test-ca.key.der

Start with the issue's ag and find commands, then inspect the remaining checked-in key paths: test/hierarchy/*.key.pem, test/test-key-5.der, and wfe2/wfe_test.go. Trace how the integration tests use these files and run the affected tests. Done means test keys are generated at test startup, no private keys remain checked in, and push protection with secret scanning is enabled.