Legacy service does not work when an index claim is returned

[hannahhoward]

What

The current content claims service, when queried for a CID, will return results from BOTH the content claims DB and the block index table. (#80)

However, the current legacy indexing service (which materializes from block index) will NOT lookup generate claims if any claims are returned from the normal indexing service (which is connected to the legacy claim store) -- https://github.com/storacha/indexing-service/blob/main/pkg/service/legacy/service.go#L54

In the case of most existing content, there is an assert/index in the old content claims DB and no others (i.e. location claims). So, the normal indexer connected ot the content claims db will return a result like this:

{
   claims: [indexClaim],
   indexes: []
}

This will cause the legacy service not to generate claims from block index tables. This is essentially the problem of not publishing location claims until recently (addressed in storacha/blob-fetcher#14), except here it actually causes queries to not succeed at all as no location claims are returned at all.

The two ways to fix it are:

1. to implement a car park fallback OR
2. to fix the check in the legacy indexing service.

I wonder if there is a way to implement this legacy indexing service at a different level as a lower level dependency. (content claims store? not sure)

[hannahhoward]

confirmed in freeway testing that we always get an index claim and nothing else, and there is nothing to be done with it.

[alanshaw]

I think it might be sufficient to change the code to only fallback when no indexes are found in the results. This signals that either the data was legacy, or was generated during the time period when we weren't publishing location claims. WDYT?

I'm keen for queries for non-legacy data to not have to hit the legacy table.