utilccl: improve CheckEnterpriseEnabled performance

[erikgrinaker]

In #59571, utilccl.CheckEnterpriseEnabled was called much more often in the read path, via kvfollowerreadsccl.canSendToFollower. However, CheckEnterpriseEnabled has a couple of performance issues:

1. We're instantiating a pgerror.Newf() in utilccl.check() when enterprise features are unavailable -- this is often necessary because we include cluster-specific info in the error message, but is expensive. However, in this specific case the caller just needs to know if there was an error, not the actual error message, so we should provide a variant using a generic, static error message.

2. We're decoding the license (if any) on each call, see:

cockroach/pkg/ccl/utilccl/license_check.go

Lines 120 to 127 in c834bd8

	// FIXME(tschottdorf): see whether it makes sense to cache the decoded
	// license.
	if str := enterpriseLicense.Get(&st.SV); str != "" {
	var err error
	if lic, err = decode(str); err != nil {
	return err
	}
	}

[blathers-crl]

Hi @erikgrinaker, please add branch-* labels to identify which branch(es) this release-blocker affects.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan.}

[nvanbenschoten]

Did we mean to label this as a GA-blocker? The performance of CheckEnterpriseEnabled did not regress in this release, did it? If not, then a fix for this will not qualify for a backport.

[erikgrinaker]

Did we mean to label this as a GA-blocker?The performance of CheckEnterpriseEnabled did not regress in this release, did it?

I initially thought much of this code was new, but then realized it was present in 20.2 and earlier -- forgot to update the labels, did so now. However, I'd imagine follower reads might get pretty expensive because of this.

If not, then a fix for this will not qualify for a backport.

Got it, thanks for the heads-up.