Fix `#current_authenticated_job` when used with `.authenticate_with`

🚓 Context

In the package team, we support many different CLIs that are used to push packages (such as $ npm, $ mvn, $ nuget or others). Each of those clients have their own rules for authentication. For example, some will use Basic Auth while others will use OAuth.

In addition to that, our users want to be able to use different "types" of tokens such as the personal access token, deploy tokens or job tokens.

Using the existing authentication methods made us not happy. Basically, the code was really hard to get and this led us to this epic: &3807. During the analysis, it became clear that the current way to authenticate for APIs is too complex to follow. In addition, it forces you to use a group of authentication methods together. In other words, the API using those functions has many "doors" available for authentication although we know for sure that only 1 door will be used. So why have n doors available, when you can only 1?

The solution we suggested is a new way to authenticate APIs. The basic idea is that, developers need to list explicitly what token types and authentication types are available.

This solution was implemented in !38627 (merged). For now, only nuget, rubygems APIs use authenticate_with but we have plans to extend its usage to all package managers APIs.

NuGet users reported (see #299685 (closed)) that packages pushed by a CI job were not properly linked to the build info. What happens is that the new way to authenticate don't properly return the #current_authenticated_job.

🤔 What does this MR do?

• Fix #current_authenticated_job when the authentication config is in namespace_inheritable.
• Add the relevant method in lib/api/helpers/authentication.rb and update the related specs
• Update the shared example that checks package uploads to check for package creation and that the package is properly linked to a ci build.
  • I can't update the rubygems spec here as they use a different authentication method that the one used in the shared examples. I opened #324645 as a follow up.

📸 Screenshots (strongly suggested)

Here is how a NuGet package pushed by a CI pipeline is displayed in the UI:

Before the MR

With the MR

📐 Does this MR meet the acceptance criteria?

Conformity

• 📋 Does this MR need a changelog?
  • I have included a changelog entry.
  • I have not included a changelog entry because _____.
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• Separation of EE specific content

Availability and Testing

• [-] Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team