Gitlab docker-runner does not mount uppercase symlinks to devices correctly
<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug
For the Enterprise Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
Gitlab docker runner does not mount uppercase symlinks to devices correctly
### Steps to reproduce
0. Prequisites:
- Gitlab-runner on Linux (here: Ubuntu Disco)
- Docker
- Gitlab-runner with Docker socket mounted into it, so it can build silbling containers
1. Udev rule: Create udev rule for existing device (example: `/dev/ttyUSB0` of a serial interface). That creates a `SYMLINK` to 'ttyUSB_Customname`
2. Mount the device (`/dev/ttyUSB0`) as well as the symlink (`/dev/ttyUSB_customname`) with settings in the Gitlabs `config.toml`
3. Build a project that uses an image and build stepts that somehow use the device (example: `file /dev/ttyUSB0`, `file /dev/ttyUSB_Customname`)
The result: `/dev/ttyUSB0` will show up and is working, `/dev/ttyUSB_Customname` is not existant in the container at all.
(How one can reproduce the issue - this is very important)
### Example Project
### What is the current *bug* behavior?
... but wait, there is more:
If we turn up the gitlab-ci build level to `debug` we see a log output that tells us that
`/dev/ttyusb_customname` is being mounted onto `/dev/ttyusb_customname` - wait a minute, why the lowercase?
If I create a lowercase symlink rule, instead of the case sensitive one - it actually works!
### What is the expected *correct* behavior?
Being able to mount symlinks to devices that include uppercase
(What you should see instead)
### Relevant logs and/or screenshots
### Output of checks
#### Results of GitLab environment info
<details>
<summary>Expand for output related to GitLab environment info</summary>
<pre>
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)
(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
</pre>
</details>
#### Results of GitLab application Check
<details>
<summary>Expand for output related to the GitLab application check</summary>
<pre>
(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:check SANITIZE=true`)
(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`)
(we will only investigate if the tests are passing)
</pre>
</details>
### Possible fixes
(If you can, link to the line of code that might be responsible for the problem)
issue