Changing the create pull request flow to work with git client library instead of REST API

[abrl91]

Related issue: #5440
While implementing the pull request flow for Bitbucket, we found some issues related to requests containing files, such as get-current-user-commit-list, create-commit, and create pull-request.

• Bitbucket doesn't have an API endpoint for the user's commit list
• Even if they support it, we need to override the commit's author because we are performing actions on behalf of the user with OAuth (the approach we are using for Bitbucket integration).
• Bitbucket doesn't support sending files in the request body, so create-commit and create-pull-request won't work as they work with GitHub.

When implementing the smart git strategy, we used a git-client library (simple-git) to clone the repository very early in the create pull request flow. Therefore, I think we can and should change the implementation to use only git commands for this process.

We already have this PR that I created as a part of the pull request flow for Bitbucket. I changed the way we deal with the commit list that we (as Amplication) committed in the repo.

There are some side effects in this PR that we need to discuss, and the same goes for the side effects that may happen if we change all the create pull request flow to work with git client lib instead of REST API.

The pros are obvious regarding performance.
The cons are all the side effects and braking changes we might have, including the one we already know about from the PR I mentioned here earlier.

[yuval-hazaz]

@abrl91 like you mentioned, the upside is clear
about the side effect you mentioned, I see it as an incomplete PR rather than a side effect. it is not that this is the final state and we must live with that. we should fix it

[overbit]

It seems clear that we would prefer, as a strategic decision, to leverage git, or any already implemented "git cli proxy", for any operation that is specifically git related (i.e. commits, pulls, push, merge, repo initialisation, etc) leaving the rest of interaction to a provider to its own APIs (for rest of interactions I speak about things like create pull request, create a repository, add comments to PR, etc)