fix type mismatch for descriptor func

[bewebi]

Description

• Add WithInjectedSnapshot() to ScaledSnapshotBuilder, allowing the user to specify a snapshot for the builder to return directly
  • Unit test
  • Use WithInjectedSnapshot() in raw snapshot table entry
• Add getter functions to allow description generator to take builder instead of snapshot
  • Update generateDesc() accordingly
• Generated routes are 0-indexed, matching generation for other resources
• Add Darwin implementation of MeasureIgnore0ns() in order to allow for running performance tests locally

Context

When working on #8415 we did not run the Nightly job performance tests for the final commit and therefore did not catch bugs that had been introduced, namely:

• A type mismatch was introduced because the generateDesc() func signature no longer matched the Entry signature for the "Benchmark table"
• Route generation was still based on 1-indexed names while Endpoints and Upstreams were switched to 0-indexing, leading to an off-by-one error and a translation warning due to routes referencing non-existent Upstreams

This PR resolves these bugs

We opt to add getter functions to ScaledSnapshotBuilder to allow generateDesc() to consume builders instead of snapshots and to add NewInjectedSnapshotBuilder() to allow arbitrary snapshots to be passed
The alternative would be to pass built Snapshots to each entry, like:

...
		Entry(nil, gloohelpers.NewScaledSnapshotBuilder().WithUpstreamCount(10).WithEndpointCount(1).Build(), basicConfig, "upstream scale"),
		Entry(nil, gloohelpers.NewScaledSnapshotBuilder().WithUpstreamCount(1000).WithEndpointCount(1).Build(), oneKUpstreamsConfig, "upstream scale"),
...

I am ambivalent between these choices, but calling Build() from within the test function seemed cleaner and, as ScaledSnapshotBuilder is an internal, test-only struct, there does not seem to be a downside to exposing getter functions on it
If reviewers feel the alternative is preferable we can go that route

In addition, we add a Darwin implementation for measurement, allowing tests to be run locally on Macs
Though the timing measurements are not actually meaningful as far as benchmarking, this will allow users to catch compilation and runtime errors without having to manually run the Nightly action
Users should continue to run the Nightly action when adding new tests in order to determine the benchmark targets

Nightly build run(s)

Add additional links if additional commits are made

• e146d3b
• 8d99208
• 445b381

Checklist:

• I included a concise, user-facing changelog (for details, see https://github.com/solo-io/go-utils/tree/main/changelogutils) which references the issue that is resolved.
• If I updated APIs (our protos) or helm values, I ran make -B install-go-tools generated-code to ensure there will be no code diff
• I followed guidelines laid out in the Gloo Edge contribution guide
• I opened a draft PR or added the work in progress label if my PR is not ready for review
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

[solo-changelog-bot]

Issues linked to changelog:
https://github.com/solo-io/solo-projects/issues/5116

[solo-changelog-bot]

Issues linked to changelog:
https://github.com/solo-io/solo-projects/issues/5116
https://github.com/solo-io/solo-projects/issues/4918

[sam-heilbron]

There are a few other pieces of cleanup that can be done since the tests no longer have the linux requirement:

1. The BeforeEach still has

testutils.LinuxOnly("uses go-utils benchmarking.Measure() which only compiles on Linux")

which can be removed
2. The comment above the tests:

// These tests only compile and run on Linux machines due to the use of the go-utils benchmarking package which is only
// compatible with Linux

Can also be either deleted or updated