replace processor call with machine call

[simskij]

the current call to platform.processor is not reliable and quite frequently returns "unknown", for instance in the CI, or on arch linux. this patch replaces all occurrences with calls to platform.machine which should be way more reliable.

[github-actions[bot]]

Libraries are not up to date with their remote counterparts. If this was not intentional, run charmcraft fetch-libs and commit the updated libs to your PR branch.

stdout

``` Library charms.alertmanager_k8s.v0.alertmanager_dispatch was already up to date in version 0.4. Library charms.grafana_k8s.v0.grafana_source was already up to date in version 0.10. Library charms.observability_libs.v0.juju_topology was already up to date in version 0.1. Library charms.observability_libs.v0.kubernetes_service_patch was already up to date in version 0.6. Library charms.prometheus_k8s.v0.prometheus_remote_write has local changes, cannot be updated. Library charms.prometheus_k8s.v0.prometheus_scrape has local changes, cannot be updated. Library charms.traefik_k8s.v0.ingress_per_unit updated to version 0.10. ```

stderr

``` ```

[rbarry82]

I wonder if this is also the cause for the unit test failure here (where the value is not mocked).

Should we fail back to x86_64? It's only arm64 and x86_64, and an equivalent to:

switch(runtime.GOARCH); {
case "arm64":
  binary = "cos-tool-arm64"
default:
  binary = "cos-tool-amd64"
}

Is probably a sane enough default

[simskij]

I wonder if this is also the cause for the unit test failure here (where the value is not mocked).

Should we fail back to x86_64? It's only arm64 and x86_64, and an equivalent to:

switch(runtime.GOARCH); {
case "arm64":
  binary = "cos-tool-arm64"
default:
  binary = "cos-tool-amd64"
}

Is probably a sane enough default

I think it's probably good that it breaks if the user were to use some other fringe architecture, allowing them to raise an issue about having the arch added instead of troubleshooting for ages.

[rbarry82]

In that case, it's probably worth using the Run-On-Arch action to ensure that these are actually set.

Whatever scenario in the GH runners (Google hasn't turned up much) which leads to flaky architecture detection should be squashed unless we intend to globally patch it at the top of every unit test. Or use Run-On-Arch

[github-actions[bot]]

Libraries are not up to date with their remote counterparts. If this was not intentional, run charmcraft fetch-libs and commit the updated libs to your PR branch.

stdout

``` Library charms.alertmanager_k8s.v0.alertmanager_dispatch was already up to date in version 0.4. Library charms.grafana_k8s.v0.grafana_source was already up to date in version 0.10. Library charms.observability_libs.v0.juju_topology was already up to date in version 0.1. Library charms.observability_libs.v0.kubernetes_service_patch was already up to date in version 0.6. Library charms.prometheus_k8s.v0.prometheus_remote_write has local changes, cannot be updated. Library charms.prometheus_k8s.v0.prometheus_scrape has local changes, cannot be updated. Library charms.traefik_k8s.v0.ingress_per_unit updated to version 0.10. ```

stderr

``` ```