Introduce logic and UI changes for different types of lock

What does this MR do and why?

This MR is a part of a bigger effort that aims to consolidate various tiny Vue apps in the header area of tree and blob view into one common Vue application.

Note: There's a potential for refactor, but that part will be handled in the following issues within &13018. The MRs for #497051 (closed) goal is to move everything as is.

I started work in !173576 (closed), but the changes were extensive. I want to have a little piece merged first to make sure the other MR is easier to review and there's less potential for errors (which I have already made re-implementing logic that was in Ruby 🙈 ).

This MR adds:

1. assigning a type of lock to pathLock that applies to the visited directory
2. adding logic for different variants of tooltip, based on the lock type, current user permissions and lock author
3. rendering an alert if any of the queries fails

---

• all changes are behind a common_repository_blob_header_app=true URL param
• elements are being moved in batches, what you're reviewing may not yet look like the old version
• breaking the work into smaller parts means that feature tests won't pass, due to missing UI elements. We will take care of the feature tests in the last step, after all other MRs are merged
• please make sure you give it a go and thoroughly test all the buttons

The breakdown of #497051 (closed) MRs:

step	status
introduce ff & move first batch of controls, move web ide button for tree header, recreate projects/tree/lock_link in Vue	✅
move code buttons (desktop & mobile) for tree header	✅
move contents of app/views/projects/blob/_breadcrumb.html.haml	✅
recreate projects/tree/lock_link in Vue	⬅️
turn on feature tests for when the ff is true	🚧

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

• Prepare common Vue app for Repository and Blob header area
• MR that introduced the UI
• Previous Ruby version of the button

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Context	Before	After
downstream lock, user with permissions
downstream lock, user with permissions that is NOT the lock's author
upstream lock, user with permissions
exact lock, user with permission that is the lock's author
exact lock, user with permission that is NOT the lock's author

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Impersonate a user with a reporter role in the project to test disabled button.
2. Go to Project overview or Code / Repository and go into one of the folders of your project.
3. Add common_repository_blob_header_app=true param to the URL
4. Make sure you have three levels deep directories that you can lock to see all types of locks:

• exact lock means that particular directory is locked
• upstream lock means the parent directory is locked
• downstream lock means the child directory is locked

5. Note: the mutation to actually lock a directory is not yet implemented. Make sure you lock a directory before testing without common_repository_blob_header_app=true (with old HAML version of the button)
6. Impersonate another user that has access to the project, with and without the permissions to edit locks. You can see slightly different tooltip copies in these scenario. Again, make sure they are the same as in the HAML version. I found it helpful to have two windows next to each other, with old and new implementation:

Note: Remember to refresh the old implementation after any change. Since it's HAML, it won't update the state of the button and I found it may temporarily show incorrect information.

Related to #497051 (closed)