Upgrade FSC to v0.20.0

[sid200727]

Closes #2351

Second of two PRs for the FSC bump. Stacks on #2356, which takes us from v0.18.0 to v0.19.0, merge that one first, or this diff will show both bumps.

The runtime panic

FSC #1700 removed HasNext() from iterators.Empty. It was never part of the Iterator interface that guarantees only Next() and Close(),but the slice and permutation iterators still have it, which is presumably how the pattern crept in here:

if err == nil && it.(interface{ HasNext() bool }).HasNext() {

cachedFetcher returns a permutation on a cache hit and an empty iterator on a miss. After the upgrade, every cache miss panics. This is production code in mixedFetcher.UnspentTokensIteratorBy, and it compiles cleanly, only the test run catches it.

The fix

cachedFetcher already knows the outcome: the ok from cache.Get. It now reports that alongside the iterator, through an unexported unspentTokensIteratorBy. UnspentTokensIteratorBy stays a thin wrapper over it, so the TokenFetcher interface and its generated mocks are untouched, and mixedFetcher no longer inspects an iterator it has no portable way to inspect.

I kept it to cachedFetcher deliberately, widening the interface method would have meant regenerating mocks/token_fetcher.go and updating the stubs in manager_test.go, ratelimit_test.go, selector_test.go and selector_iterator_test.go, which felt out of proportion for this.

Other breaking changes in this range

FSC #1711 (squirrel removal) also lands here. As confirmed during that PR's review, it needs no source changes on our side, go mod tidy just drops the stale indirect requirements.

Testing

-> All eight modules build, go vet and golangci-lint (v2.12.2, the pinned version) clean
-> Verified the panic's provenance: sherdlock panics on v0.20.0 without this fix, and does not on v0.19.0, so the break arrives with this bump
-> The remaining sherdlock failures and the identity/config TestTranslatePath failure are pre-existing on main and unrelated

Possibly worth a follow-up

The same assertion pattern may exist elsewhere in Panurus, or in other FSC consumers. I only checked sherdlock because that's what failed.
Happy to open a separate issue if that seems worth sweeping for.

[adecaro]

Review: does this fully address #2351?

@sid200727

Approve, with non-blocking comments — the panic fix is correct and verified, two points from @Effi-S's earlier review rounds remain open at this commit.

Checked out fix-2351-bump-fsc-v0.20.0 at 141a87a and verified:

go build ./... (each of the 9 modules individually)         -> clean, all 9
go vet ./token/services/selector/sherdlock/...               -> clean
go test -count=1 ./token/services/selector/sherdlock/...      -> pass
go test -race -count=1 ./token/services/selector/sherdlock/...-> pass, no races
golangci-lint run ./token/services/selector/sherdlock/...     -> 0 issues
revert fetcher.go fix + re-run tests                          -> panics exactly as described

I also read the vendored FSC v0.20.0 source directly to confirm iterators.Empty's empty[K] struct really did drop HasNext() after FSC PR #1700, and grepped the repo for other callers of the same fragile it.(interface{ HasNext() bool }) pattern — found none outside this file.

Reverting fetcher.go's mixedFetcher.UnspentTokensIteratorBy back to the pre-fix type assertion and re-running the suite panics with panic: interface conversion: *iterators.empty[...] is not interface { HasNext() bool }: missing method HasNext at fetcher.go:110, so the existing test suite pins the bug rather than the diff inventing new coverage.

CI has not run yet on this commit — all checks except DCO show pending (fork PR awaiting workflow authorization) — so none of the above is corroborated by CI; all verification here is from local runs.

What it fixes

#	Finding	Verified
2351.1	FSC v0.20.0 removed HasNext() from the empty iterator, causing a panic on cache miss	✅ confirmed against vendored FSC source, reproduced the panic by reverting the fix
2351.2	Fix avoids the panic without widening the public TokenFetcher interface/mocks	✅ confirmed — unspentTokensIteratorBy is unexported, UnspentTokensIteratorBy signature unchanged

Both rows are solid; the underlying fix is small, correct, and test-covered.

Non-blocking

• Still open from your earlier review: fabric-smart-client/integration is left at v0.18.0 in every go.mod that references it (e.g. cmd/tokengen/go.mod:18), even though the root FSC module moved to v0.20.0 here. I confirmed integration/v0.20.0 genuinely exists upstream via git ls-remote --tags, so this isn't a "can't go further" case.
• Still open from your earlier review: the cache-hit invariant (cached=true implies the cached slice is non-empty) is enforced by construction in groupTokensByKey/updateCache, not at the unspentTokensIteratorBy boundary itself, and the updated test (fetcher_test.go:176-186) now only asserts the cached flag rather than the iterator's actual content — so a future regression that violates the invariant would pass silently.
• Hygiene: PR body says "Refs #2351" rather than Fixes #2351/Closes #2351, so GitHub won't auto-link or close the issue on merge.

Recommendation

Good to merge as-is; the two open threads from @Effi-S are worth resolving in this PR or a fast follow-up, and the Fixes #2351 wording is a one-line fix to the PR body whenever convenient.

[adecaro]

Design note: cache-hit invariant (cached=true implies non-empty) is enforced by construction elsewhere, not at this boundary.

cached here is just whether f.cache.Get found the key — it doesn't check the iterator actually has tokens. Today that's safe because groupTokensByKey (fetcher.go:294-308) only appends to m[key] when a token is found, and updateCache (fetcher.go:312-334) deletes any stale key not present in the newest batch — so no key can ever map to an empty slice. But nothing at this boundary enforces that; it's implicit in two other functions.

This is the same concern @Effi-S raised on this line in the prior review round — still open at this commit, restating with the concrete trace of where the invariant actually lives.

Suggestion: add a short comment here documenting the invariant, or assert on it directly (e.g. treat a cache hit with an empty slice as a bug rather than trusting it can't happen).

[adecaro]

Should fix: this now only asserts the cached flag, not that the iterator actually yields a token.

The old assertion (it.(interface{ HasNext() bool }).HasNext()) confirmed the cache hit actually produced tokens. The new one (assert.True(t, cached, ...)) would still pass if a future change let cached=true coincide with an empty iterator — exactly @Effi-S's concern from the prior review round on this test.

Suggestion: additionally assert on the iterator's content, e.g. tok, err := it.Next(); require.NoError(t, err); assert.NotNil(t, tok), so a regression in the invariant discussed on fetcher.go:362-372 would actually fail this test.

[sid200727]

Thank you @adecaro for the detailed review, and for reproducing the panic against the vendored source, that's more verification than I'd done myself.
Taking all three: the boundary guard on the cache-hit invariant, the fabric-smart-client/integration bump across the eight go.mod files, and Refs → Closes in the PR body. The first two are the same points @Effi-S raised earlier and I should have addressed them in the previous round.

[sid200727]

Bumped fabric-smart-client/integration, it turned out to need more than the version line. FSC #1642 refactored the topology package, so Chaincode.Policy is gone (we were setting SignaturePolicy to the same value anyway), AddNamespaceWithUnanimity is replaced by AddNamespace with a topology.Unanimity policy, and AddNamespace now takes a typed EndorsementPolicy plus options. Three call sites, all migrated. Only go build verifies these locally the integration suites need a full network.

[adecaro]

Hi @sid200727 , if it is okay, I'll close this. There were many things to change to make the integration tests passing again.
I have fixed what was necessary in #2360.

Thanks for you effort. I learned from it 🙏

[sid200727]

Of course, go ahead and close it. That's the right call, the integration side needed a working fabric-x environment to iterate on, and CI round-trips weren't a sensible way to get there.

Glad the sherdlock fix and the UpdateChaincode / FABRIC_X_BINS findings were useful.
Thank you @adecaro @Effi-S for picking it up, and for the reviews along the way, I learned a lot from them too 🙏

[adecaro]

thanks @sid200727 🙏