The security fix EZSA-2018-001 ensured that the names of protected content could not be leaked by making content/node links to it. The links would normally be rendered as URL aliases, which leaks the content name. After the fix, links are rendered empty.

This is not good in some situations. It may be better to have a functional link, which would then lead the users to a login form, since they don't have access. However, we can't use URL aliases since this leaks information of protected content.

Proposal: When users don't have access to linked content, the link should be rendered as a node link, like /content/view/full/42. When the users do have access, it should be rendered as an URL alias, as currently.

Steps to reproduce
1. Install eZ Publish Platform 5.4 or 5.3, or eZ Platform 1.13 with LegacyBridge.
2. Log in to the backend as administrator.
3. Find some content the anonymous user has read access to (let's call it "public_content" in this test).
4. Find some content the anonymous user does not have read access to, like the admin user object ("secret_content").
5. Create an article the anonymous user has read access to. In the XML text, add object relation links to public_content and secret_content. Publish the article.
6. Go to the frontend as anonymous user, and view the article. Verify that the link to public_content looks and works as normal. Verify that the link to secret_content is empty (links to the front page root)
7. Apply the PR https://github.com/ezsystems/ezpublish-legacy/pull/1355 - Clear content cache or republish the article.
8. Go to the frontend as anonymous user, and view the article. Verify that the link to public_content looks and works as normal. Verify that the link to secret_content is a node link (/node/view/full/[some ID]) and not an url alias, and that clicking it leads to an access denied page.
9. Edit legacy settings/ezxml.ini, change ShowURLAliasForProtectedLinks to enabled. Clear content cache or republish the article.
10. Go to the frontend as anonymous user, and view the article. Verify that the link to public_content looks and works as normal. Verify that the link to secret_content looks like a normal url alias, and that clicking it leads to an access denied page.
11. Go to the frontend as administrator, verify that both links look and work as normal.