Renaming fetch/metadata web platform tests

[chromium-wpt-export-bot]

Bug: 1011285

Change-Id: I8f96a36e7fd0a27dde66671c3c85e298236d20f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1838173
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Yifan Luo <lyf@google.com>
Cr-Commit-Position: refs/heads/master@{#702780}

[wpt-pr-bot]

Already reviewed downstream.

[foolip]

wpt-firefox-nightly-stability failed on Taskcluster with this at the end of the log:

Unstable results

Test	Subtest	Results	Messages
/fetch/metadata/redirect/multiple-redirect-https-downgrade-upgrade.tentative.sub.html	Https downgrade-upgrade prefetch => No headers	FAIL: 4/5, TIMEOUT: 1/5	assert_unreached: Reached unreachable code;Test timed out

And:

::: Running tests in a loop 10 times : PASS
::: Running tests in a loop with restarts 5 times : PASS
::: Running tests in a loop 10 times with flags chaos_mode_flags=3 : PASS
::: Running tests in a loop with restarts 5 times with flags chaos_mode_flags=3 : FAIL

[foolip]

https://github.com/web-platform-tests/wpt/pull/19501/files#diff-e8cd438d992009752968a4484d55a7de is the part of the change that renamed and updated that file, but the only changes are removing "sec-" from some paths.

In https://wpt.fyi/results/fetch/sec-metadata/redirect/multiple-redirect-https-downgrade-upgrade.tentative.sub.html?run_id=308860001&run_id=316900003&run_id=308870001&run_id=314890002, clicking the history button, one can also observe this subtest timing out in the past.

Here's a sequence of 5 runs showing the flakiness:
https://wpt.fyi/results/fetch/sec-metadata/redirect/multiple-redirect-https-downgrade-upgrade.tentative.sub.html?run_id=339980016&run_id=340000009&run_id=340000008&run_id=316770011&run_id=332440010

@KyleJu this is a prime example of existing flakiness that the tooling your building is going to help with. Starting from a PR like this where one has determined a test to be flaky, what would the steps to add that metadata be? The instructions for that should ideally be easy to find from the failure itself, so maybe the logs of stability jobs should say something about this?

I'll admin merge this now.

@jgraham FYI