renamed Metrics to MetricsState and move to a separate file

[nirrozenbaum]

This PR renames the struct Metrics (under backend/metrics) to MetricsState and move it to a separate file (extracted from types.go).

currently in the repo there are many different places that uses the terminology 'metrics', which makes it confusing to a newcomer to understand where do we define what metrics we collect, and where is the metrics latest state.
This PR aims to solve this issue, as the changed struct holds the state of the scraped metrics from a pod (the values may change every scraping interval).

Additionally, not only this change improves readability of current code, it's also a first PR out of a bigger change.
on follow up PRs, the concept of ServerState (a general purpose interface) will be introduced and is representing a state of data that is collected/scraped from a pod (this is part of data layer and extensible pod scrapers).
MetricsState will the first use of that interface once the interface is introduced.

This PR has NO LOGIC CHANGE.

[netlify]

✅ Deploy Preview for gateway-api-inference-extension ready!

Name	Link
🔨 Latest commit	aa85778
🔍 Latest deploy log	https://app.netlify.com/sites/gateway-api-inference-extension/deploys/6822363f63573300082b2e1a
😎 Deploy Preview	https://deploy-preview-822--gateway-api-inference-extension.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[nirrozenbaum]

CC: @kfswain @ahg-g @liu-cong

[nirrozenbaum]

/retest

[kfswain]

If we are going to pull this out of the types file. Should we pull the factory out as well? If we want a type per file, should we turn types into a directory?

[nirrozenbaum]

the direction I was thinking of can be seen in #783 that was closed in favor of splitting the changes into a series of smaller PRs. I think each data scraper should have a directory and inside that directory the structs should be flattened. if it's more convenient you can see in the PR branch an example here:
https://github.com/nirrozenbaum/gateway-api-inference-extension/tree/model-scraper/pkg/epp/backend/metrics

so, at the end of this bigger change, I don't think we'll need types directory nor types.go file.

[nirrozenbaum]

factory has to go through more changes than extracting from types, so that's for another PR

[kfswain]

Small comment about repo structure, also I'm not sold on MetricsState as the name, but that doesn't have to block. Are we just trying to use the -State suffix to indicate that struct is intended to be generalized data storage?

[nirrozenbaum]

Small comment about repo structure, also I'm not sold on MetricsState as the name, but that doesn't have to block. Are we just trying to use the -State suffix to indicate that struct is intended to be generalized data storage?

in the previous (and bigger) PR that was closed I called it xxx-data. but as I was thinking about that more, suffix -state sounds better to me, since it's the CURRENT STATE of the scraped data. and this state can change in next scraping iteration.
I thought about this difference (but maybe it's just my interpretation):
data is something I collect and accumulate, while latest state is struct I just update with latest values.

anyway, I'm open to any name that makes sense.
the name is just a small detail here as long as we agree on the end goal.

[kfswain]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kfswain, nirrozenbaum

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 [kfswain]

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