Fix issues indexer document mapping

[wolfogre]

Fix regression of #5363 (so long ago).

The old code definded a document mapping for issueIndexerDocType, and assigned it to BleveIndexerData as its type. (BleveIndexerData has been renamed to IndexerData in #25174, but nothing more.) But the old code never used BleveIndexerData, it wrote the index with an anonymous struct type. Nonetheless, bleve would use the default auto-mapping for struct it didn't know, so the indexer still worked. This means the custom document mapping was always dead code.

The custom document mapping is not useless, it can reduce index storage, this PR brings it back and disable default mapping to prevent it from happening again. Since IndexerData(BleveIndexerData) has JSON tags, and bleve uses them first, so we should use repo_id as the field name instead of RepoID.

I did a test to compare the storage size before and after this, with about 3k real comments that were migrated from some public repos.

Before:

[ 160]  .
├── [  42]  index_meta.json
├── [  13]  rupture_meta.json
└── [ 128]  store
    ├── [6.9M]  00000000005d.zap
    └── [256K]  root.bolt

After:

[ 160]  .
├── [  42]  index_meta.json
├── [  13]  rupture_meta.json
└── [ 128]  store
    ├── [3.5M]  000000000065.zap
    └── [256K]  root.bolt

It saves about half the storage space.

[KN4CK3R]

Does this migrate the existing index or does it reindex everything?

[wolfogre]

Does this migrate the existing index or does it reindex everything?

It will reindex everything. We have no way to migrate indexes, either bleve or es.

[GiteaBot]

I was unable to create a backport for 1.20. @wolfogre, please send one manually. 🍵

go run ./contrib/backport 25619
...  // fix git conflicts if any
go run ./contrib/backport --continue

[wolfogre]

I was unable to create a backport for 1.20. @wolfogre, please send one manually. 🍵

go run ./contrib/backport 25619
...  // fix git conflicts if any
go run ./contrib/backport --continue

Since this PR is based on #25174 which is a refactor and hasn't been backported to v1.20, so it's difficult to backport this one. So I think it's OK to leave the old code in v1.20.