remove indexable columns limitation in split-duckdb-index
Needed for https://github.com/huggingface/datasets-server/pull/1418
Option 1: Since we need all the split datasets with the duckdb file for /filter, I propose just removing the limitation in the job runner as a noninvasive change.

Pending:

- [X] update tests
- [X] migration to add default field as has_fts=True for the existing cache records with status 200 


~~Option 2:~~
~~As an alternative, I think we could split the tasks into two separate runners:~~
~~- split-duckdb-data: in charge of data ingestion for the duckdb file only.~~
~~- split-duck-index: in charge of indexing the existing table only if indexable columns exist (might need to first download the previous one and generate a new one + the index).~~
~~But there could be open questions: Will we keep only one file in the repo? Should we have two separate files in the repo? (one for data and another for data+index)?~~
remove indexable columns limitation in split-duckdb-index: Needed for https://github.com/huggingface/datasets-server/pull/1418
Option 1: Since we need all the split datasets with the duckdb file for /filter, I propose just removing the limitation in the job runner as a noninvasive change.

Pending:

- [X] update tests
- [X] migration to add default field as has_fts=True for the existing cache records with status 200 


~~Option 2:~~
~~As an alternative, I think we could split the tasks into two separate runners:~~
~~- split-duckdb-data: in charge of data ingestion for the duckdb file only.~~
~~- split-duck-index: in charge of indexing the existing table only if indexable columns exist (might need to first download the previous one and generate a new one + the index).~~
~~But there could be open questions: Will we keep only one file in the repo? Should we have two separate files in the repo? (one for data and another for data+index)?~~