Keep the whole table index when caching dynamic filter matches

[arpitjain099]

filterAllowedIndices took the index of a matching row with

pduArray := strings.Split(pdu.Name, ".")
index := pduArray[len(pduArray)-1]

which is only the last sub-identifier. That is right for a table indexed by a single integer, and wrong for anything else. jnxBgpM2PeerTable in #1687 is indexed by routing instance plus a local and a remote InetAddress, so every matching row cached the same trailing byte, and addAllowedIndices then built a GET for an OID that does not exist. The target metric simply goes missing, with nothing in the logs pointing at the index.

The index is everything after the filter's own OID, so indexFromOID now takes that, tolerating a leading dot on either side (gosnmp emits names both ways) and returning empty for a PDU outside the filter's subtree, which is then skipped rather than cached as a bad index.

Two tests. TestFilterAllowedIndicesCompositeIndex uses the issue's table and asserts both the cached indices and the GET OIDs that come out of addAllowedIndices, since that is where the damage actually shows. Against the current code it fails the way the report describes, with two distinct peers collapsing onto one index:

got [2 2], want [0.1.4.10.0.0.1.4.10.0.0.2 0.2.4.10.0.1.1.4.10.0.1.2]
got [1.3.6.1.4.1.2636.5.1.1.2.1.1.1.11.2 1.3.6.1.4.1.2636.5.1.1.2.1.1.1.11.2], want [...11.0.1.4.10.0.0.1.4.10.0.0.2 ...11.0.2.4.10.0.1.1.4.10.0.1.2]

TestIndexFromOID covers the parsing directly, including the case that would be easy to get wrong with a plain TrimPrefix: 1.3.6.1.2.1.2.2.1.80.2 is not under 1.3.6.1.2.1.2.2.1.8.

The existing TestFilterAllowedIndices is untouched and still passes, which is the single-component case. go test ./... and go vet ./... are clean.

Verified against unit tests only; I do not have a Juniper device to reproduce the original walk on.

Fixes #1687