Speed up issue counting for a project

What does this MR do?

Three meaningful commits, three changes:

1. Skip confidentiality checks not only for admin users (who can see all issues), but when we are searching in a single project, and the current user has access to view all confidential issues in that project. See https://gitlab.com/gitlab-org/gitlab-ce/issues/33913#note_33000332 for the query plans and the difference the confidentiality check makes.
2. Cache the total issue and MR counts for a project by user 'type' (can see all / none / some confidential issues), and reuse that cache for the issue and MR state tabs when there are no filters applied (which is the default when you click on the tab). See https://gitlab.com/gitlab-org/gitlab-ce/issues/33913#note_32984005 for an interesting bug that currently exists, which is fixed by this commit.
3. When someone is not a project member with access to view confidential issues, and we're just counting issues, treat them as if they couldn't see any. This does mean that the counts will be wrong for them if they created or are assigned to a confidential issue, but means we don't have an explosion in cache keys.

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

1. Do we want all of these changes?
2. Should user_can_see_all_confidential_issues? and user_cannot_see_confidential_issues? be private instead, with a cache_key method exposed from the IssuableFinder itself?

Why was this MR needed?

This was crazy slow 😢

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Tests
  • Added for this feature/bug
  • All builds are passing
• Conform by the merge request performance guides
• Conform by the style guides
• Branch has no merge conflicts with master (if it does - rebase it please)
• Squashed related commits together

What are the relevant issue numbers?

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/33913.