Return HTTP 301 to client when redirect occurs for old DSpace 6.x URLs

[tdonohue]

Describe the bug
Follow-up to #1147

The Google Scholar team noted that when older-style /handle URLs (e.g. /handle/[prefix]/[suffix]) are redirected to new URLs (e.g. /items/[uuid]), the redirect does not return an HTTP 301 Moved Permanently to the client. Instead, a 200 OK is returned (and the redirect happens via Javascript).

To Reproduce
Steps to reproduce the behavior:

1. Find the /handle/[prefix]/[suffix] for a Community, Collection or Item.
2. Open up your browser's DevTools, "network" tab for the current page.
3. Paste the /handle/[prefix]/[suffix] URL in your browser's address bar. Notice in DevTools that a 200 OK is returned even though the redirect occurs (internally via JavaScript)

Expected behavior
Ideally the redirect should occur via 301 (or 302) response code. This allows crawlers to be notified properly of the redirect and avoids the page being indexed twice under two different URLs.

Related work
Related to initial redirect work in #1147

[tdonohue]

@artlowel : Pinging you on this one just in case you are aware of a "quick fix" that we could apply (since your team designed this code a while back). If there is not one, we may need to investigate a better way to do these redirects in the future.

[tdonohue]

Talked again with the Google Scholar team today. Verified this feature is only needed on the server side. They are using SSR content when indexing DSpace 7 sites. In order for these older DSpace 6 URLs to be replaced in the Google Scholar index, a 301 Moved Permanently Redirect should be returned when a DSpace 6 URL is redirected to a DSpace 7 URL.