Namespace license checks for fast-forward merge when possible

Related to https://gitlab.com/gitlab-org/gitlab-ee/issues/2335

Use fast-forward merged where possible (EES / Bronze)

1. Do not show radio option for fast-forward merge on project settings page

2. How to handle for future cases where this has already been set?

Introduced in https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/485 by @dzaporozhets

mentioned in issue #2570 (closed)

mentioned in issue #2571 (closed)

Related to https://gitlab.com/gitlab-org/gitlab-ee/issues/2570 and https://gitlab.com/gitlab-org/gitlab-ee/issues/2571

@dzaporozhets How much effort do you estimate it will take to find all places that touch fast-forward merge and add project.feature_available?(:fast_forward_merge) checks to them (both on frontend and backend), so that this feature can be turned off for a specific project in its entirety by having that method return false?

mentioned in issue #2335 (closed)

@DouweM approx 4 hours. ownership of this issue?

@dzaporozhets OK, thanks. I'll be assigning people for 9.4.

assigned to @nick.thomas

We have to decide which merge method to use when a project has fast_forward_merge set, but the license does not allow it.

Are we happy to use "Merge commit", or should it be "Merge commit with semi-linear history" ?

It feels like the second is closer to the suggested action than the first?

/cc @dzaporozhets

mentioned in merge request !2272 (merged)

On second thought, we should be acting as though we are CE when the feature isn't available. This means we should use the merge strategy.

closed via merge request !2272 (merged)

mentioned in commit 62d05c23