SQLite backed cache

[rmweir]

Issue:
rancher/rancher#45635
Refers to the Informer-based, SQLite-backed Steve caching ("Vai") RFC

Reviewing:
I recommend starting with the pkg/cache/sql/README.md. If lasso/controller understanding is limited then read the main README.md first. Once you understand of what informer/indexer/indexer's store generally are and how they work, then move on to the those components of the on-disk cache. A lot of this PR is tests- starting with non-testing files at first should simplify review.

Testing:
In addition to passing the unit tests provided in this PR, a version of rancher using this PR has been tested with the integration tests located here.

[ericpromislow]

Only remaining issue is that go test ./... fails with type-related errors in function calls

[tomleb]

Had some pending comments I never sent. Nit, some clarifying questions, with the assumption that we want to merge and do some more work after in rancher/rancher#45635.

I'd have like to look at the partition bit but Michael already did a good job reviewing there so I'll look at it post-merge.

[tomleb]

@moio I had some concern about some of the cache.Indexer / cache.Store methods panicking (ListIndexFuncValues, List and ListKeys). I understand that those interface don't allow us to return an error, which is a bummer, but I'm wondering if panicking is the best we can do here given that this is a library.

Have we thought about other ways of handling these failing cases (eg: returning an empty list)? Is this something we could perhaps revisit in rancher/rancher#45635? Panicking seems pretty brutal for something that could have been SQLite being busy, as an example.

[moio]

@moio I had some concern about some of the cache.Indexer / cache.Store methods panicking (ListIndexFuncValues, List and ListKeys). I understand that those interface don't allow us to return an error, which is a bummer, but I'm wondering if panicking is the best we can do here given that this is a library.

Have we thought about other ways of handling these failing cases (eg: returning an empty list)?

To be honest, no, but I see your point.

Is this something we could perhaps revisit in rancher/rancher#45635? Panicking seems pretty brutal for something that could have been SQLite being busy, as an example.

SQLite being busy is addressed by retrying code already, and the number of retries should be so high for that to signal a real bug rather than a temporary condition (or at least, that was the design intent).

But I agree there might be other causes and panic might be inappropriate. I added a point to the epic issue and welcome discussion on alternatives.

-> epic

[moio]

Only remaining issue is that go test ./... fails with type-related errors in function calls

Tests all pass now, dismissing review.

tests pass now