connect: Leaf Cert ModifyIndex not being incremented properly

[kyhavlov]

The ModifyIndex of leaf certs is being set based on the CAConfig table rather than something that increments with every new leaf cert signed. This means a proxy can request a new cert for a refresh and get back a cert with the same ModifyIndex, which could cause an edge case where a proxy doesn't get its certificate updated properly.

[banks]

In addition, the current approach of relying on the built-in CA to touch the CAProvider table on each sign to increase index (even if we implemented it right) doesn't work for Vault CA.

Once we build metadata support for certificates (planned for later in the year) all the problems go away but I suggest for now we use an explicit counter in the indexes table or something to ensure blocking and cache invalidation happens correctly.

Concretely it mostly works right now because if the proxy is actually blocking for a new leaf at the time the leaf rotates, the cache layer will deliver the new cert and cache it regardless of the index being the same.

Where it would fail now is it makes rotation racey. The following is possible (but never reproduced in practice yet):

1. leaf rotation triggered by something (CA change or leaf near expiry)
2. CSR Sign RPC sent to server
3. Proxy gets to the end of blocking leaf query timeout and returns current leaf
4. Sign RPC returns the new cert (with same ModifyIndex as the previous one due to this bug)
5. Cache framework updates the cert in cache but still with same index
6. Proxy issues next blocking long poll with same index it had before
7. cache sees that the cert "hasn't changed" since indexes match and blocks waiting on next rotation

In this case the proxy will miss the certificate rotation and may end up loosing connectivity if the next rotation doesn't happen until it's current certificate has expired.