FINERACT-2421: Rework Github Actions workflow

[adamsaghy]

Description

This PR is trying to improve on multiple ways of our CI execution:

Having a common action to setup and build Fineract -> action.yml

Uploading and archiving artifacts (logs) only if workflow job fails. In case of success, these are not relevant anymore -> No need to upload and store them (except workspace...)

Retention days to be reduced to 5 day: More than enough to evaluate logs, no need to further collect and store them

Compression level to be increased, even the used artifact storages should be minimal -> Consideration for users who are running Fineract CI on private repo or their own runner.

Timeout: Increased timeout to ensure, even if the job is queued for a longer time, still fit into the timeframe

Limiting branches to be used to execute full CI -> By default only develop (later main) and releases and tags to be considered

Adding concurrency group and cancel prior execution in case a CI execution is triggered on a newer version of the code changes / PR

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

Your assigned reviewer(s) will follow our guidelines for code reviews.

[meonkeys]

Please add a description

[meonkeys]

I like being able to just grab the entire workspace and tinker with it. That really helped when I was debugging failing cucumber tests... I was able to try the same :fineract-provider:cucumber in both my local workspace and in the downloaded workspace.

I get that it is a good chunk of storage to deal with, though.

What's the benefit/effect of moving logic from .github/workflows/build-core.yml into .github/actions/setup-and-build-fineract/action.yml?

[adamsaghy]

I like being able to just grab the entire workspace and tinker with it. That really helped when I was debugging failing cucumber tests... I was able to try the same :fineract-provider:cucumber in both my local workspace and in the downloaded workspace.

I get that it is a good chunk of storage to deal with, though.

What's the benefit/effect of moving logic from .github/workflows/build-core.yml into .github/actions/setup-and-build-fineract/action.yml?

@meonkeys Its the same now, and we probably stick with building workspace and reuse it.

This change was merely refactoring, so it can be reused (which is not at the moment...)

[Aman-Mittal]

Ready for merge, Tests are running OK , NO security issues i have found, and re run is working ok on single shard.