Resolve "Remove help text regarding group issues on group issues page (and group merge requests page)"

Tip from
https://robots.thoughtbot.com/write-reliable-asynchronous-integration-tests-with-capybara#directly-interacting-with-javascript

Resolve "Remove help text regarding group issues on group issues page (and group merge requests page)"

Tip from
https://robots.thoughtbot.com/write-reliable-asynchronous-integration-tests-with-capybara#directly-interacting-with-javascript

The locale code is turned into an asset path with an underscore
instead of a dash.

The language codes are transformed by `I18n.locale` into a code with a
dash. But the resources for translating are always stored in a path
using a `_` separating the language and the region code.

When there are no groups defined in the auth hash attributes,
`Gitlab::Saml::AuthHash#groups` should return an empty array, and
`Gitlab::Saml::User#find_user` should not mark the user as external.

Closes gitlab-org/gitlab-ce#38923.

In API v4 when requesting a branch with an invalid refname shows an
helpful error message: 'The branch refname is invalid'.

Security fixes for 10.1 RC

See merge request gitlab/gitlabhq!2209

The problem would occur when the `ForkedProjectLink` was deleted, but
the `ForkNetworkMember` was not. The delete would be rolled back and
retried.

But the error would not be saved because `Project#forked?`
would still be true, because the `ForkNetworkMember` exists. But the
`Project#forked_project_link` would be `nil`. So the validation for
the visibility level would fail.

When a build is retried automatically, we close any open todos. However, we do
that _before_ creating a new build failed todo.

To solve this, we check if the build is retried before creating the todo. We
also ensure that the build _instance_ has the correct attribute set, without
needing to reload it from the database.

On GitLab.com, we see that cron jobs sometimes don't run. This appears to be
because the process that polls for current cron jobs only has a 60 second
validity period, so if (for whatever reason) it misses those 60 seconds, we have
to wait until the next execution.

For the usage ping, this is particularly problematic, as that's only scheduled
to run once a week.

Changing it to run for every minute in a 10 minute period should work around
this, if the above diagnosis is correct. The job itself obtains an exclusive
lease for 24 hours, so rescheduling in quick succession is safe.