[WIP] Fix data race caused by blevesearch/bleve

[typeless]

For #5189

[lunny]

So many files changed and it's difficult to review.

[typeless]

@lunny This PR has not been finished yet.

[lunny]

@typeless see #5224, that will fix getOwnerName data race.

[typeless]

I based the PR on the master of blevesearch/bleve. Are we going to upgrade to the latest bleve?
If not, I would have to rebase this on the vendored version, which would also reduce the size of diffs.

But how will it look like if I make changes on a vendored package? AFAIK, the Makefile would reject any local change to the vendor directory.

[typeless]

Fixing it upstream is a bit of cumbersome, it would be great if I can fix it in Gitea alone like #5224

[lunny]

@typeless update the vendor could be a standalone PR. Is this data race made by https://github.com/blevesearch/bleve, https://github.com/ethantkoenig/rupture or gitea's code?

[typeless]

@lunny See https://github.com/ethantkoenig/rupture/blob/master/flushing_batch.go#L60-L67

The method Batch would spawn a goroutine which reads the pointer fields of b.batch.

Meanwhile, the following Reset method call of b.batch would update the value of the pointers, which results in the data race.

I can not prove if the map entries (other than the value of the map itself) of b.batch are safe or not. So, I added sync.Map for it also, which might not be a good idea.

Because the goroutine is spawned inside the bleve code, it's hard to predict the behavior from upper layers.

[lunny]

Would you like to continue this PR or maybe we could close this one.

[typeless]

Got it. Won't have time to work on this in the near future.