Update CI and switch to python 3.11

[danielhfrank]

Background

• refs google.cloud.datastore add_filter warnings #56 (comment)
• Updates existing CI errors and tries to maintain behavior in the face of changing dependencies

Description

• Updates setup-gcloud workflow in CI to current version (easy)
• Business logic test failures were due to behavior changes in fsspec that affected the glob function, see Make glob consistent with glob.glob fsspec/filesystem_spec#1382 and Better double asterisks ** support fsspec/filesystem_spec#1329 . I changed one test whose expectations were no longer valid, and otherwise changed a bit of application logic to match the pre-existing behavior
• Additionally, began running tests on 3.11, and some tests broke on behavior around an StrEnum alternative that we were using. Elected to switch to just test on 3.11 (per slack), and bring in the stdlib StrEnum

Discussion

• The fsspec changes crept into scope because we don't pin our dependencies, but rather specify minimum versions. Thus it was possible to pull in the breaking changes automatically, and since we don't develop in this repo often, not notice. We might consider either pinning dependencies, or running tests on main periodically. I assume that we don't pin dependencies in order to maintain this codebase as a "library" that other codebases can pull in and have control over their own deps. In those circumstances, we might consider scheduling a weekly CI run or something

cc @ravwojdyla

[dhimmel]

LGTM. Let's give @ravwojdyla some time to review since he'll be most familiar with whether the small number of functional changes could have unintended consequences.

[dhimmel]

We might consider either pinning dependencies, or running tests on main periodically. I assume that we don't pin dependencies in order to maintain this codebase as a "library" that other codebases can pull in and have control over their own deps. In those circumstances, we might consider scheduling a weekly CI run or something

I'm in favor of unpinned dependencies with scheduled CI so we're aware of whether anything breaks due to upstream changes.

[ravwojdyla]

Nice, I remember this being inconsistent across FSs, and I remember disliking this logic a lot, is there any chance to simplify the current implementation now given the (assumption!) more consistent glob results?

[danielhfrank]

Mm, I gave it another read-through, and I don't see too much wrong with it. If anything, I guess I could see using the more consistent glob behavior to change what glob patterns were used upstream, but that sounds like potentially a complicated effort to track down callsites.. and moreover, I don't think it would rank high on the list of company objectives 😉

[danielhfrank]

• Since you two reviewed, I added a scheduled test run in f7b1074. Will merge now, and you should be clear to run tests on google.cloud.datastore add_filter warnings #56