Fallback to the single offset if possible and version can't be parsed

[RonFed]

The main goal of this PR is to handle cases where an offset is required for a package with an un-official version (contains commit hash: for example v0.0.0-20230227094218-b8c73b2037b8
Currenly we can't handle such cases since we don't find a valid version.
I added a fallback to check if only a single offset were saved across all versions to use that offset. If more than one offset was saved and the version is not foundd, fail.
A more robust solution is probably required to handle this kind of version, but this fallback is a good solution until then.

[MrAlias]

What are the consequences if the offset is wrong here? I'm guessing the best case scenario is the telemetry contains garbage, but is the worse case that the user application crashes?

I worry that this guess becomes problematic at the end of the version range. If a user is asking for an offset that is released after our last know version we have less confidence that value hasn't changed. Can we address that?

[MrAlias]

What are the consequences if the offset is wrong here? I'm guessing the best case scenario is the telemetry contains garbage, but is the worse case that the user application crashes?

I worry that this guess becomes problematic at the end of the version range. If a user is asking for an offset that is released after our last know version we have less confidence that value hasn't changed. Can we address that?

[RonFed]

What are the consequences if the offset is wrong here? I'm guessing the best case scenario is the telemetry contains garbage, but is the worse case that the user application crashes?

I worry that this guess becomes problematic at the end of the version range. If a user is asking for an offset that is released after our last know version we have less confidence that value hasn't changed. Can we address that?

It depends if the offset is used to read from or write to the user app. Most (all except one that I can think of) of the offsets are used for attribute collection, so a wrong offset will lead to garbage value in the worst case (some probes drop the span if an attribute cna't be read, maybe we should change that). For those we use for writing (adding HTTP header for example), a wrong offset can cause a crash in the worst case. There are a lot of checks in the eBPF code in the writing to user memory parts, to minimize that chance, and the only case which I can think of this might happen is the HTTP header update (the offset there is part of the standard library)

Regarding newer versions, we can identify this case as a different one from the hash commit version and maybe act differently?