Handle unit length valueFrom values

[rexagod]

What this PR does / why we need it: Handle unit length valueFrom values and skip strings where we expect them to be type-cast-able to float64, instead of erroring, since that is the expected behavior, and what's being done for other types.

How does this change affect the cardinality of KSM: No change.

Which issue(s) this PR fixes: Fixes #1947

[logicalhan]

/triage accepted
/assign @mrueg

[mrueg]

Can we add another Test for this path

							// This means we are here: [ <string>, <int>, ... ] (eg., [ "foo", "0", ... ], i.e., <path>.foo[0]...
							//                           ^
							// Skip over.
							return nil```

[rexagod]

This is actually another bug in and of itself. Basically, the same one but for multi-length valueFrom paths. In the spirit of keeping the changesets digestible and throughly tested and reviewed in the CRS realm, I'm thinking if it'd be a good idea to target that in another PR (and getting the unit-length path fix in this release)?

---

JFYI the test below returns nil for both main and this PR.

		{
			name: "multiple path-relative valueFrom values", each: &compiledGauge{
				compiledCommon: compiledCommon{
					path: mustCompilePath(t, "spec"),
					labelFromPath: map[string]valuePath{
						"version": mustCompilePath(t, "version"),
					},
				},
				ValueFrom: mustCompilePath(t, "order", "-1", "id"),
			}, wantResult: []eachValue{
				newEachValue(t, 3, "version", "v0.0.0"),
			},
		},

[mrueg]

Sounds good to me! Can you add a TODO to the code path?

[mrueg]

can we add another check for sValueFrom[len(sValueFrom)-1] == ']' ?

[mrueg]

I can confirm your change is fixing #1947.
/approve

I would like to get a second pair of eyes on the implementation from @kubernetes/kube-state-metrics-maintainers

[dgrisonnet]

/assign
/hold

I asked some questions in #1947. It is unclear what we are trying to achieve here.

[dgrisonnet]

This is a bit odd to me. ValueFrom is orginally a string array and here we are manually trying to parse it as a string and extracting the first element from it, when we should have an easy access to it. What do you think about adding a new method to valuePath that would return a string array instead of a raw string?

[dgrisonnet]

@rexagod I am merging the PR without that change since it is mostly code quality related, but if my suggestion makes sense to you, let's address that in a follow-up

[dgrisonnet]

/lgtm
/approve
/unhold

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dgrisonnet, mrueg, rexagod

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dgrisonnet,mrueg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment