[ResourceTiming] Add test for new TAO check

[chromium-wpt-export-bot]

This CL modifies the tests as follows:

• '' is now the default TAO header. This means most sandwich tests use ''.
• Another resource is added to crossorigin-sandwich-TAO to test the case in
  which the header is the page origin, and this should now fail (this was the
  test before this CL).
• The resources in crossorigin-sandwich-TAO are changed to images because it's
  not super clear how iframes will be handled.

Bug: 1022816
Change-Id: I2110653a5240cff825d3130cfe6dc64e8d2f8e23
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1924635
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
Cr-Commit-Position: refs/heads/master@{#716652}

[wpt-pr-bot]

The review process for this patch is being conducted in the Chromium project.

[npm1]

Ok, I did not see that this is complaining and the Chromium patch landed, woops. Some things:

• Looks like the commit message gets copy-pasted, which in this case results in some deformation because for example * is parsed differently.
• The failure seems to be caused by duplicate test message "fetchStart > 0 in cross-origin redirect.". Was there a way to catch this problem without looking at the GitHub PR? I forgot this was a rule...

@foolip for help! If my reading is right and the problem is just the test messages, I can fix that but I don't want to unsync the chromium and GitHub version further.

[Hexcles]

Chatted with @npm1 . The test_* helper functions generate subtests (they call test at the end), not just assertions, so the third argument is actually the test name not the message.

[npm1]

Ah still failing... @Hexcles the Firefox failure seems to be caused by Firefox computing separate timestamps which means sometimes the values will be close but not equal and other times the values will be equal (so the test is considered flaky). Can we force-merge in this case?

[Hexcles]

Firefox computing separate timestamps which means sometimes the values will be close but not equal and other times the values will be equal

This sounds to me like an implementation problem. I'm not a domain expert so I'll trust your judgement here (file a bug to Firefox if needed.)

[foolip]

Thanks @Hexcles for helping out with this!