fix: Apl 307 apl-charts repo creation

[Ani1357]

This PR adds an extra check in the apl installation job which checks the presence of the apl-charts repo in gitea. It uses the git ls-remote command to do so and in case the repo is there it will skip cloning it again which was previously causing issues when the job did not finish in the first attempt.

Validation steps:

1. Deploy APL from this branch
2. What for the installation job to start and monitor its logs
3. When you see this line in the logs: otomi:cmd:commit:gitea-apl-charts:info Cloning apl-charts in Gitea, then kill the pod so a new one resumes the installation
4. The second pod should finish the installation without errors

[merll]

It seems this approach does not work reliably. I tested this and from an installation with one failed and one successful pod, it reads apl-charts repository already exists in Gitea twice. When I check the repo after successful installation, it is empty.

Generally git ls-remote works, but one would need to check for non-empty output, in addition to the exit code. It seems this is what the $`git ls-remote ... ` should be doing, but it does not. For comparison, if I create a token and run the following bash code, I get

❯ if [[ -z $(git ls-remote https://$T1@gitea.merll-1.dev-akamai-apl.net/otomi/values.git) ]]; then echo empty; else echo not empty; fi
not empty

❯ if [[ -z $(git ls-remote https://$T1@gitea.merll-1.dev-akamai-apl.net/otomi/charts.git) ]]; then echo empty; else echo not empty; fi
empty

[Ani1357]

@merll great catch. I updated the code to check for a non-empty reply.

[merll]

I can confirm this works as intended now.