Add random suffix to common name for sqlsslcerts to avoid collision

[mortenlj]

In some situations, a sqlinstance might have existing certs for an application that we don't know about in the cluster. If we try to make new certs with the same common name, it will fail, and the only solution is to use the gcp console to remove the previous cert.

By adding a random suffix, we avoid those collisions, at the cost of some additional certs on the instance that we in probably have lost anyway.

[Kyrremann]

Fin fix, men dette betyr vel at vi vil i noen tilfelle ha sertifikater liggende som ikke er i bruk, som skulle vært slettet? For vi har jo hatt problemer med brukere som sletter appen sin, og så blir ikke sertifikatet slettet, og når de oppretter appen på nytt så vil de med denne løsningen bare få et nytt sertifikat.

[mortenlj]

Fin fix, men dette betyr vel at vi vil i noen tilfelle ha sertifikater liggende som ikke er i bruk, som skulle vært slettet? For vi har jo hatt problemer med brukere som sletter appen sin, og så blir ikke sertifikatet slettet, og når de oppretter appen på nytt så vil de med denne løsningen bare få et nytt sertifikat.

Det stemmer, men jeg anser problemet som verdt å se bort i fra, av to grunner:

• I disse situasjonene så er i praksis det eksisterende sertifikatet tapt, dvs. det finnes ingen kopier som kan benyttes
• Det er grenser for hvor mange ganger man sletter og gjenoppretter, så omfanget vil være svært lavt

I bytte slipper vi en hel del problemer rundt opprettelse av nye sertifikater der CNRM hverken lar oss sjekke hvilke som finnes eller ta over eksisterende[^1].

[^1]: Sagt på en annen måte: vi kan ikke løse problemet uten å lage en ny operator som kjører ved siden av CNRM og ser etter sqlsslcert ressurser som havner i denne staten, og så bruker google APIer for å slette sertifikatet på instansen, noe som fremstår som fryktelig mye jobb for en veldig liten gevinst.