Improve perf on label key validation

[marcoandredinis]

> go test -benchmem '-run=^$' -bench '^BenchmarkIsValidLabelKey' github.com/gravitational/teleport/api/types/common
goos: darwin
goarch: arm64
pkg: github.com/gravitational/teleport/api/types/common
cpu: Apple M3 Pro
BenchmarkIsValidLabelKeyNew-12          16505014                72.53 ns/op            0 B/op          0 allocs/op
BenchmarkIsValidLabelKeyOld-12           1333614               898.9 ns/op             0 B/op          0 allocs/op
PASS
ok      github.com/gravitational/teleport/api/types/common      2.639s

[smallinsky]

nit: don't have strong opinion:

Suggested change

	func isValidLabelKeyByte(b byte) bool {
	switch b {
	case
	// Digits
	'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
	// Lowercase letters
	'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm',
	'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',
	// Uppercase letters
	'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M',
	'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z',
	// Allowed symbols
	'/', '.', '_', ':', '*', '-':
	return true
	default:
	return false
	}
	func isValidLabelKeyByte(b byte) bool {
	return ('0' <= b && b <= '9') || // Digits
	('a' <= b && b <= 'z') || // Lowercase letters
	('A' <= b && b <= 'Z') || // Uppercase letters
	b == '/' || b == '.' || b == '_' || b == ':' || b == '*' || b == '-' // Allowed symbols
	}

[espadolini]

On my cpu this is actually a tiny bit faster (82ns/op vs 89ns/op) but it depends on the data (it becomes worse after adding another test case that has a lot of symbols), I think that the big switch table gives the compiler the best chance to optimize the code now and in the future with better bitwise and numerical tricks (that being said, the chain of conditions and the switch are equivalent so a Sufficiently Smart Compiler should just generate the exact same code for both, but that's basically a pipe dream for Go unfortunately).

I also prefer the aesthetic of the table of letters and numbers. 😌

[espadolini]

Suggested change

	for i := 0; i < b.N; i++ {
	for range b.N {

[espadolini]

What do you think of constraining this test file (or a secondary file for the benchmark) to go 1.24 instead of using b.N?

[espadolini]

Suggested change

	var labelsForBenchmark = []string{
	labelsForBenchmark := []string{

[espadolini]

On my cpu this is actually a tiny bit faster (82ns/op vs 89ns/op) but it depends on the data (it becomes worse after adding another test case that has a lot of symbols), I think that the big switch table gives the compiler the best chance to optimize the code now and in the future with better bitwise and numerical tricks (that being said, the chain of conditions and the switch are equivalent so a Sufficiently Smart Compiler should just generate the exact same code for both, but that's basically a pipe dream for Go unfortunately).

I also prefer the aesthetic of the table of letters and numbers. 😌