LUB of a bivariant parameter is not fully general #41044

In #40570, I removed bivariance somewhat aggressively. One area where we are not quite doing the right thing, it appears, is when computing the LUB/GLB of a bivariant type parameter. The code currently just picks one side, which seems clearly wrong, but I was not able to craft a test case exploiting that. Therefore, opening an issue to revisit later if we can get a concrete test case.

This comment explains my preferred fix:

I think you are correct about the eventual result but I wouldn't expect it to be derived immediately from the LUB computation. Since the last parameter is considered "bivariant" (i.e., derived from constraints on the others), I'd expect that the last parameter simply gets a fresh variable, and that trait selection will constrain it (ultimately) to be 'c. In other words, the result from LUB itself would be Foo<fn() -> &'?0 u32, '?1> where 'a: '?0 and 'b: '?0, but enforcing the WF requirements would ultimately constraint '?1 = '?0.

However, it occurs to me that I'm not entirely sure where these WF requirements would get enforced. Much of the code assumes that the resulting types from LUB operations etc are well-formed, and hence I'm not sure when we would add such an obligation. (One possibility is to have the LUB/GLB operation itself produce an obligation, at least if bivariance is involved, given that this is now a possibility.)