rpk: Improve k8s bundle errors + better admin API fallback

[r-vasquez]

Debug bundles are often collected when things are not working properly, so it is normal that rpk debug bundle hits some errors along the collection steps. This PR aims to improve the error messages and provide better hints when errors occur, it focuses on the Kubernetes experience.

Fixes #18057

Main Changes:

1. rpk uses the k8s API to 'find' the admin API addresses and collect the logs, this is the first step that leads many other steps, if the service account does not have the authorization to access some resources it will fail. Now we check for the authorization before executing the steps, reducing the clutter and providing a better error message:

# Before:
	* unable to get pods in the "redpanda" namespace: pods is forbidden: User "system:serviceaccount:redpanda:default" cannot list resource "pods" in API group "" in the namespace "redpanda"
	* unable to get pods in the "redpanda" namespace: pods is forbidden: User "system:serviceaccount:redpanda:default" cannot list resource "pods" in API group "" in the namespace "redpanda"

# Now:

	* skipping log collection and collecting Kubernetes resources (such as pods, services, etc.) in the namespace "permission denied to list services". To enable this you may need to grant additional permissions to your service account; visit https://docs.redpanda.com/current/manage/kubernetes/troubleshooting/k-diagnostics-bundle/

2. Our fallback in the case of (1) was to use localhost:9644 for the admin API addresses, we are now using the loaded profile's addresses as the primary fallback since it includes TLS information as such. This does have a big impact on clusters that were created using our helm chart/operator since we now populate the redpanda.yaml with the cluster admin API addresses:

# Before
	* unable to issue request for "admin/disk_stat_cache_127.0.0.1-9644.json": Get "https://127.0.0.1:9644/v1/debug/storage/disk_stat/cache": tls: failed to verify certificate: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs
	* unable to issue request for "metrics/127.0.0.1-9644/t0_public_metrics.txt": Get "https://127.0.0.1:9644/public_metrics": tls: failed to verify certificate: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs
	* unable to issue request for "admin/node_config_127.0.0.1-9644.json": Get "https://127.0.0.1:9644/v1/node_config": tls: failed to verify certificate: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs
	* unable to issue request for "admin/raft_status_127.0.0.1-9644.json": Get "https://127.0.0.1:9644/v1/raft/recovery/status": tls: failed to verify certificate: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

# Now: use the profile, which would have the TLS configuration in place :smile: 

3. /proc/slabinfo collection often fails because rpk debug bundle is not being executed with root permissions:

# Before: 
open /proc/slabinfo: permission denied
# Now:
open /proc/slabinfo: permission denied; you may need to run the command as root to read this file

4. Controller log collection requires the presence of redpanda.data_directory in the configuration file (redpanda.yaml), this is also necessary to start Redpanda, so it is often a sign of a corrupted or invalid config file. The error we were printing was not a clear indication of that

# Before:
	* lstat redpanda/controller/0_0: no such file or directory
# Now: 
	* failed to save controller logs: 'redpanda.data_directory' is empty on the provided configuration file

5. If a command execution failed (du, top, etc...) we would print that the command exited with status 1, and the error (stderr) is saved in the file. Our error did not provide a hint that this was the behavior, this is now clear:

# Before:
* couldn't save 'utils/dmidecode.txt': exit status 1

# Now:
* couldn't save 'utils/dmidecode.txt': exit status 1; utils/dmidecode.txt contains the full error message

$ cat utils/dmidecode.txt
# dmidecode 3.3
/sys/firmware/dmi/tables/smbios_entry_point: Permission denied
Scanning /dev/mem for entry point.
/dev/mem: Permission denied

Backports Required

• none - not a bug fix
• none - this is a backport
• none - issue does not exist in previous branches
• none - papercut/not impactful enough to backport
• v24.1.x
• v23.3.x
• v23.2.x

Release Notes

Improvements

• rpk debug bundle now fallback to loaded profile's admin API URLs if we fail to discover the cluster in the collection steps.

[andrewhsu]

@r-vasquez when you get the chance, can you rebase this PR on top of tip of dev branch to get the changes that were merged in PR #19625 to address gha triage job failure?

[vbotbuildovich]

ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/50122#01900911-f28e-4ad4-8a01-59c50aa2f669

[r-vasquez]

/backport v24.1.x