Group URLs leak information

When visiting the group URL (e.g., example.com/groups/foobar) of a group that exists but is not public, an empty group page is returned, which leaks the existence of a group with that name to users not authorized to have that information (such as, for example, users not signed in, or signed-in users without the relevant permissions).

Steps To Reproduce

1. Sign out of a Gitlab instance.
2. Visit the URL of a group known to exist on that server, but without public projects, directly (i.e., by typing it into the URL bar).

This also works for signed-in users:

1. Sign in to a Gitlab instance
2. Visit the URL of a group known to exist, but without public projects, to which the current user does not have any access, directly (i.e., by typing it into the URL bar).

Expected Behavior

To avoid leaking information, the response should be identical to that of trying to access a group that does not exist. (See #3352 (closed) for discussion of the appropriate error code.)

Observed Behavior

A Gitlab page for an empty group is displayed, confirming the existence of a group to which the current user does not have access.

Output of Checks

This can be observed on gitlab.com.