Fix builds tab visibility

closes #23951

See merge request !7178

# Conflicts:
#   app/workers/project_web_hook_worker.rb

Fix lightweight tags not processed correctly by GitTagPushService

## What does this MR do?

Fix lightweight tags not processed correctly by GitTagPushService

## Are there points in the code the reviewer needs to double check?

No

## Why was this MR needed?

Lightweight tags were being processed incorrectly, causing tag triggers to receive wrong information and not function properly.

## Does this MR meet the acceptance criteria?

- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
  - [ ] Added for this feature/bug
  - [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?


Closes #22271

See merge request !6532

Optimize Event queries by removing default order

See merge request !7130

Remove unreferenced LFS objects from DB and fs

Fixes #3666

See merge request !5901

Remove unreferenced LFS objects from DB and fs

Fixes #3666

See merge request !5901

Bump gitlab-shell version to 4.0.0

New version includes https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/102 and needed for https://gitlab.com/gitlab-org/gitlab-ce/issues/2772

See merge request !7200

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Improve docs on `gitlab-ci-token` user

See merge request !6002

Restrict teaspoon tasks introduced by !6059 to development environment.

Otherwise we get syntax errors in production environment, see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6059#note_17597729

See merge request !7189

Fixed sticky MR tabs positioning when sidebar is pinned

## What does this MR do?

The sticky MR tabs where positioned underneath the pinned sidebar. This fixes that by accounting for the size of the pinned nav.

## Screenshots (if relevant)

![Screen_Shot_2016-10-28_at_09.37.18](/uploads/0d23f2bb0e02d698c012c22c8653afd7/Screen_Shot_2016-10-28_at_09.37.18.png)

## What are the relevant issue numbers?

Closes #23926

See merge request !7167

Do not allow text input in dropdown while loading

## What does this MR do?
It moves the focus event of the text input of a filterable dropdown to after loading of options is complete. After the fix, the user cannot edit the while it's greyed out and loading.
## Are there points in the code the reviewer needs to double check?

## Why was this MR needed?
It fixes the bug in https://gitlab.com/gitlab-org/gitlab-ce/issues/23496.
## Screenshots (if relevant)
![https://gitlab.com/gitlab-org/gitlab-ce/uploads/a7bc2f0228fcde5a85cccb333b52f0e3/2016-10-18_12.00.54.gif](https://gitlab.com/gitlab-org/gitlab-ce/uploads/a7bc2f0228fcde5a85cccb333b52f0e3/2016-10-18_12.00.54.gif)

## What are the relevant issue numbers?
Fixes #23496

See merge request !7054

Closes #23926

Only remove right connector of first build of last stage

Only remove right connector of first build of last stage.
Closes #23849

See merge request !7179

Make internal api work with full repo path and name

## What does this MR do?

Make internal api work with full repo path and name

## Why was this MR needed?

So we can pass full repository path on filesystem from gitlab-shell instead of extracted one. We need this for nested groups support where project is can be nested under several groups. 

## What are the relevant issue numbers?

https://gitlab.com/gitlab-org/gitlab-ce/issues/2772

See merge request !7148

Create cycle analytics bundle

## What does this MR do?

Currently the cycle analytics file is being included in our application.js file & therefore including VueJS in application.js. This MR creates a cycle analytics bundle and only includes it on the cycle analytics page.

See merge request !7176

While loading, the entire dropdown is greyed out. However, The focus is on the text input, so user can input text. Move the focus event to after loading finished to fix this.

add "x of y tasks completed" on issuable

Closes #22392

See merge request !6527

Fix CHANGELOG for GH import fixes

See merge request !7173

When we updated gitlab_git to 10.4.1, `tag.target` changed from pointing
to the sha of the tag to the sha of the commit the tag points to. The
problem is that only annotated tags have `object_sha`s, lightweight tags
don't (it's nil), so (only) in their case we still need to use
`tag.target`.

Merge branch 'ee-1159-allow-permission-check-bypass-in-approve-access-request-service' into 'master'

Allow Members::ApproveAccessRequestService to accept a new `:force` option

## What does this MR do?

See the commit message.

This is a backport of the EE fix for https://gitlab.com/gitlab-org/gitlab-ee/issues/1159: gitlab-org/gitlab-ee!830

See merge request !7168

Merge branch '23872-members-of-group-that-has-project-access-getting-404-on-accessing-a-project-issue' into 'master'

Fix project member access for group links

Closes #23872.

See merge request !7144

fix issues pointed out in !6527

add task completion status feature to CHANGELOG

Pass user instance to Labels::FindOrCreateService or skip_authorization: true

## What does this MR do?

It fixes a bug described in #23694 when `project.owner` was passed to `Labels::FindOrCreateService`. `Labels::FindOrCreateService` expected a user instance and `project.owner` may return a group as well. This MR makes sure that we either pass a user instance or `skip_authorization: true`.

## Are there points in the code the reviewer needs to double check?

- places where we pass `skip_authorization: true`

## Does this MR meet the acceptance criteria?

- Tests
  - [x] Added for this feature/bug
  - [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

Fixes #23694

See merge request !7093

This prevents VueJS being included in application.js & therefore included on everypage

Use optimistic locking

## What does this MR do?
Removes the usage of pessimistic locking in favor of optimistic which is way cheaper and doesn't block database operation.

Since this is very simple change it should be safe. If we receive `StaleObjectError` message we will reload object a retry operations in lock.

However, I still believe that we need this one: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7005 as this will reduce a load on Database and FS.
This changes a behavior from:

### Pesimistic locking (previous behavior)

#### For updating
1. SELECT * FOR UPDATE (other updates wait on this)
2. we update ci_pipeline
3. latest_build_status
4. enqueue: (use: transition :created -> :pending)
5. [state_machine] we are in  state created, we can go to pending
6. [state_machine] ci_pipeline.status = created
7. [state_machine] ci_pipeline.save
8. [state_machine] after_transition: (if for success): PipelineSuccessWorker on Sidekiq
9. release DB lock

#### If no update is required
1. SELECT * FOR UPDATE (other updates wait on this)
2. we update ci_pipeline
3. latest_build_status
4. we are in pending, we can't transition to pending, because it's forbidden
5. release DB lock

### Optimistic locking (implemented by this MR)

#### For updating
1. latest_build_status
2. enqueue: (use `transition :created -> :pending`)
3. [state_machine] we are in state created, we can go to pending
4. [state_machine] ci_pipeline.status = created
5. [state_machine] ci_pipeline.save
6. [state_machine] [save] where(lock_version: ci_pipeline.lock_version).update_all(status: :created, updated_at: Time.now)
7. [state_machine] [save] unless we_updated_row then raise ObjectInconsistentError

#### If no update is required
1. we update ci_pipeline
2. latest_build_status
3. we are in pending, we can't transition to pending, because it's forbidden

## Why was this MR needed?
We have been seeing a number of problems when we migrated Pipeline/Build processing to Sidekiq. Especially we started seeing a lot of blocking queries.

We used a pessimistic locking which doesn't seem to be required. This effectively allows us to fix our issues with blocked queries by using more efficient method of operation.

## What are the relevant issue numbers?
Issues: https://gitlab.com/gitlab-com/infrastructure/issues/623 and https://gitlab.com/gitlab-com/infrastructure/issues/584, but also there's a bunch of Merge Requests that try to improve behavior of scheduled jobs.

cc @pcarranza @yorickpeterse @stanhu

See merge request !7040

Delete issue board welcome cookie

## What does this MR do?

This was seen in the idea to production demo, because the project had already existed on the exact same URL the cookie already existed which meant the blank state wasn't shown. 

This MR deletes the cookie on project create.

See merge request !6899

This param allows to bypass permission check. It is useful for LDAP-sync
where even owners don't have the :admin_group_member permission.

See
https://gitlab.com/gitlab-org/gitlab-ee/blob/6081c37123abae4570f78831b33c2f45f92c2765/app/policies/group_policy.rb#L38
and https://gitlab.com/gitlab-org/gitlab-ee/issues/1159Signed-off-by: Rémy Coutable <remy@rymai.me>

Replace static fixture by generated one in issue_spec.js

## What does this MR do?

- clean up `issue_spec.js`
- introduce an alternative approach to #19445
  - rename `rake teaspoon` to `rake teaspoon:tests`
  - introduce `rake teaspoon:fixtures` which generates fixtures using RSpec
  - introduce `rake teaspoon` which runs `rake teaspoon:fixtures` and `rake teaspoon:tests`

## Why was this MR needed?

- many duplications
- missing existence checks
- missing conditions
- static fixtures don't match real views

## Reasoning

I want to explain some of my decisions here, so that they stay visible for future discussions.

### Why not HAML?

- same number of HAML templates as number of fixtures (many input files)
- embedded logic less readable
- can not be rendered by JavaScript (because of inline Ruby)

### Why RSpec?

- real controllers for fixtures
- spys available for mocking
- easily report failed fixture generations

### Why not magic_lamp? (#19445)

- introduces another dependency/tool
- needs to run a server concurrently to teaspoon
- makes it harder to use a JavaScript test runner
- static HTML files serve faster

See merge request !6059

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

These changes are targeted for 8.13.2, not 8.14.