Release `3.0.0` - Githubissues

Release Checklist

Attention: the examples below use the version x.y.z but you should update them to use the version you're releasing.

[x] Decide on a version number based on the current version number and the common rules defined in Semantic Versioning. E.g. x.y.z.
[x] Update this ticket name to reflect the new version number, following the pattern "Release x.y.z".
[x] Cut a branch for the new release out of the develop branch, following the gitflow naming pattern release/x.y.z.

[x] Update the project's version in [package.json] accordingly.
[x] Update the [CHANGELOG.md] with the new version number and release notes.
[x] Run tests and linting, and make sure the version running in the default branch is working end-to-end. At least the minimal end-to-end manual tests is mandatory.
[x] 🚨 DO NOT RELEASE before holidays or weekends! Mondays and Tuesdays are preferred. This doesn't apply if you're releasing a release-candidate (pre-release).

🚨 ATTENTION: in the following steps, do merge commits and NOT squash-and-merge!

[x] When the team is confident the release is stable, you'll need to create two pull requests:
- [x] release/x.y.z -> main: This PR should be merged with a merge commit. #192
- [x] release/x.y.z -> develop: this should be merged after the main branch is merged. This PR should be merged with a merge commit. #193

[x] After the release branch is merged to main, create a new release on GitHub with the name x.y.z and the use the same changes from the [CHANGELOG.md] file. – v3.0.0
- [x] The release should automatically publish a new version of the docker image to Docker Hub. Double check if that happened. – stellar/stellar-disbursement-platform-frontend:3.0.0