Remove unused GetAllGlobs override in ProjectLink

[arunchndr]

Fixes #
Perf ddrits regression in ProjectServices implementation of this.

Context

This GetAllGlobs override is unused anymore since CPS has been changed to use the GetAllGlobs(evaluationContext)

Changes Made

Remove newly added GetAllGlobs override.

Testing

Notes

[benvillalobos]

This PR is meant to fix our DDRITs regression on Build_Ngen_InvalidAssemblyCount here: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/312576

Build_Ngen_InvalidAssemblyCount reports the number of assemblies that encountered an error during ngening at VS setup. If assemblies are not ngened, it can result in more jitting in scenarios where such assemblies execute, which in turn can result in elapsed and CPU time regressions in such scenarios.

So why would ngen'ing fail here when there's an extra overload? Or was this method caught being jitted? Not sure I fully understand how a regression like this gets caught.

Either way I've applied exp-branch label, which means we should check the exp branch RPS results before merging 🙂

[arunchndr]

This PR is meant to fix our DDRITs regression on Build_Ngen_InvalidAssemblyCount here: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/312576

Build_Ngen_InvalidAssemblyCount reports the number of assemblies that encountered an error during ngening at VS setup. If assemblies are not ngened, it can result in more jitting in scenarios where such assemblies execute, which in turn can result in elapsed and CPU time regressions in such scenarios.

So why would ngen'ing fail here when there's an extra overload? Or was this method caught being jitted? Not sure I fully understand how a regression like this gets caught.

Either way I've applied exp-branch label, which means we should check the exp branch RPS results before merging 🙂

That message is misleading, I am reading the error as 2 newly failed assemblies that skew the count and not new assemblies.

[benvillalobos]

That message is misleading, I am reading the error as 2 newly failed assemblies that skew the count and not new assemblies.

That makes sense, I'm just wondering how ngen failed on an assembly because of the PR that caused it.

Here's the VS PR that will unblock this if it passes RPS: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/312854

[benvillalobos]

Note that the hashcheck failed, currently rerunning to be safe.

[AR-May]

Note that the hashcheck failed, currently rerunning to be safe.

hash checks are now fine, one of the symbol checks fails, but I suppose it should fail because this is an exp branch insertion.
The previous PR also had exactly this symbol check failure which was gone for the main branch insertion.