roachprod: pass --tenant-scope on cert gen from old binaries

[healthy-pod]

Previously, TLS client certs were scoped to the system tenant by default. After #97585, they became valid for all tenants by default (unless --tenant-scope is pass).

This caused the multitenant-upgrade roachtest to fail when certs are generated using the latest roachprod binary from an old cockroach binary.

This change ensures that such certs are not scoped to the system tenant only by passing --tenant-scope.

Release note: None
Epic: none

Closes #97016

[cockroach-teamcity]

This change is 

[knz]

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @ajstorm, @healthy-pod, @smg260, and @srosenberg)

---

pkg/roachprod/install/cluster_synced.go line 1233 at r1 (raw file):

rm -fr certs
mkdir -p certs
VERSION=$(%[1]s version | grep "Build Tag:" | sed -e 's/Build Tag:[[:space:]]*//' | cut -d- -f1)

VERSION=$(%[1]s version --build-tag)
VERSION=${VERSION::3}
if [[ $VERSION = v22 ]]; then
   ...

This makes me think we might want to backport my change to v22.1 and v22.2 and call it a day. Do we still expect to publish v22.1 releases? what do you think?

[healthy-pod]

VERSION=$(%[1]s version --build-tag)
VERSION=${VERSION::3}
if [[ $VERSION = v22 ]]; then
   ...

Nice

This makes me think we might want to backport my change to v22.1 and v22.2 and call it a day. Do we still expect to publish v22.1 releases? what do you think?

My concerns are

1. We would have to wait for a 22.2.x release to have the multitenant-upgrade test running normally again.
2. A more general solution (i.e. in roachprod) will be future proof
3. cli: don't scope TLS client certs to a specific tenant by default #97585 changes the behaviour of a flag. Would it still meet backport requirements?