fix: Handle Kubernetes API conflicts properly for signing keys

[nabokihms]

Running two dex instances in HA mode in the Kubernetes cluster, we are constantly receiving messages like this from one instance:

{"level":"info","msg":"keys rotated, next rotation: 2020-10-08 15:33:14.700531412 +0000 UTC","time":"2020-10-08T09:33:14Z"}

And errors from another instance:

{"level":"error","msg":"failed to rotate keys: PUT https://*****/apis/dex.coreos.com/v1/namespaces/******/signingkeies/openid-connect-keys Conflict: response from server \"{\"kind\":\"Status\",\"apiVersion\":\"v1\",\"metadata\":{},\"status\":\"Failure\",\"message\":\"Operation cannot be fulfilled on signingkeies.dex.coreos.com \\\"openid-connect-keys\\\": the object has been modified; please apply your changes to the latest version and try again\",\"reason\":\"Conflict\",\"details\":{\"name\":\"openid-connect-keys\",\"group\":\"dex.coreos.com\",\"kind\":\"signingkeies\"},\"code\":409}\"","time":"2020-10-09T09:33:16Z"}

This happens because both instances get the same next rotation time from a single openid-connect-keys object and start rotating synchronously. In the case of using Kubernetes storage, we have to treat the conflict response code from Kubernetes API as a result of the work of the second instance.

P.S. Error errAlreadyRotated located on the server level. I tried to avoid mixing it with the storage code. Need to figure out the right way to propagate errors from the storage level to the server level (but it does not influence the main idea of this PR).

[bonifaido]

LGTM @nabokihms !