[photon-lib] Invalidate pose cache when setting referencePose

[kcooney]

Setting PhotonPoseEstimator.referencePose now resets the pose cache, even
if there was not a previous reference pose value.

Previously, the pose cache would only be cleared if the estimator had a
reference pose and was updated to a different reference pose value, which
is likely not what users may expect.

Fixes #2039

Java changes:

• Fix (and simplify) PhotonPoseEstimator.checkUpdate()
• Update PhotonPoseEstimatorTest.cacheIsInvalidated() to verify the fix

Python changes:

• Fix (and simplify) PhotonPoseEstimator._checkUpdate()

• Update photonPoseEstimator_test.test_cacheIsInvalidated() to verify the
  fix

• Add PipelineTimestamps in the test package (to make it easier to
  ensure that PhotonCameraResult.getTimestampSeconds() returns non-
  negative values)

• Fix pyright errors in photonPoseEstimator_test.py

C++ changes:

• Update PhotonPoseEstimatorTest_PoseCache_Test to confirm this bug did
  not exist in the C++ code

Other changes:

• Fix photon-lib/py/buildAndTest.sh to specify the shell, to not assume
  that the current directory is the one with the script, and to not assume
  that bdist_wheel was installed

[samfreund]

I'd prefer that we not close #2039 after this PR because it will still apply for Java.

[kcooney]

I'd prefer that we not close #2039 after this PR because it will still apply for Java.

Agreed. Wasn't sure on the proper way to associate this PR with that bug without auto-closing the bug at merge time.

[samfreund]

I'd prefer that we not close #2039 after this PR because it will still apply for Java.

Agreed. Wasn't sure on the proper way to associate this PR with that bug without auto-closing the bug at merge time.

If u mention it that links it. I just edited it, let me know if that looks good to you.

[kcooney]

I'd prefer that we not close #2039 after this PR because it will still apply for Java.

The Java code was trivial to fix and verify, so pushed a commit to fix that as well.

Note I have not confirmed whether this exists in the C++ code.

It does not happen in the C++ code; updated the tests to confirm.

[samfreund]

@kcooney looks like you got a failing test.

[kcooney]

looks like you got a failing test.

@samfreund when I looked, all checks were reported as passed (excluding 3 skipped tasks). Rebased from main and pushed again, and GitHub is reporting "All checks have passed" 🤷‍♂️

[samfreund]

looks like you got a failing test.

@samfreund when I looked, all checks were reported as passed (excluding 3 skipped tasks). Rebased from main and pushed again, and GitHub is reporting "All checks have passed" 🤷‍♂️

Lemme rephrase, looks like we have a flaky test 💀. Sorry about that!

[Gold856]

Whoops, that’s my bad. I reran the failing job and forgot to mention that. Sorry!

[mcm001]

On mobile but seems reasonable to me

[Gold856]

The time units are different in Python between PipelineResult and PipelineMetadata? Weird, but the new test utils seem pretty nice for handling that. LGTM

[mcm001]

We should probably make that consistent in follow on work