When `force` is set to `true` and `start_branch` is set, the
branch will be ovewritten with the new commit based on the
`HEAD` of the `start_branch`.

This commit includes changes to update the `gitaly-proto` gem.

With this action the user can update the execute_filemode of a given file in the repository.

For directories application_settings --> labels.

Partially addresses #47424.

Attempted commits were failing due to the pre-recieve LfsIntegrity
check. This is skipped during tests making this failure silent.

Updates Files::MultiService for the commits API which is in turn used by the
multi-file upload web UI

Ensures that files which should be in LFS are transformed into LFS pointers
Uses Lfs::Transformer which then links LfsObjectProjects on success

- Apply some refactoring for code reuse
- Add file status validation for Files::DeleteService
- Write additional specs

When commiting multiple files we're now checking if any of those files
has been modified by another commit and we're rejecting the new commit
in this case.

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_19747556

more consistent across different methodst

Rails by default use autoload for all dirs from app folder.
require_relative not needed. See ActiveSupport::Dependencies.autoload_paths

If `source_branch` option is passed, and target branch cannot be found,
`Repository#update_branch_with_hooks` would try to create a new branch
from `source_branch`.

This way, we could make changes in the new branch while only firing
the hooks once for the changes. Previously, we can only create a new
branch first then make changes to the new branch, firing hooks twice.
This behaviour is bad for CI.

Fixes #7237

add docs and tests - add additional validation
allow move without content
updated response