`minio-service` added for Charmed Kubeflow 1.8 should be moved to kfp-api to avoid bugs with deploying multiple minios at once

Bug Description

[the minio-service added to minio charm to fix an upstream kfp bug]

while prepping for the KF 1.8 release, minio-operator 151 added a new service called minio-service to the minio charm. This service was added because upstream kubeflow pipelines has an issue where it hard-codes the minio service name.

I propose we revert minio-operator 151 and instead fix the bug in kfp by adding this svc/minio-service to the kfp-api charm. The main reasons are:

as-is, we cannot deploy two instances of the minio charm in the same model (both minio's will deploy a service of the same name, at best with one overwriting the other). This is an issue because sometimes we have a minio for kubeflow + another minio for mlflow
as-is, the service that fixes a kfp bug is added for everyone, not just kfp. If we deploy mlflow+minio, the service is added anyway even though it isn't needed

In general, the minio-service is something not needed by minio, just to fix a kfp bug, so it doesn't feel right imo to put it in the minio charm

canonical / minio-operator

`minio-service` added for Charmed Kubeflow 1.8 should be moved to kfp-api to avoid bugs with deploying multiple minios at once #153

Bug Description

To Reproduce

Environment

Relevant Log Output

Additional Context