WorkerAutomation cached per Civ - BFS cached

[SomeTroglodyte]

Resolve #4840
Brings the Next-Turn of the save included in the issue from almost 1000 seconds (my box, before ZOC) to 360s (with ZOC) by reusing city-to-city BFS'es on a Civ/Turn level. All kudos to @xlenstra for the idea. Greetings to @avdstaaij - we're going to compensate that cost away - I hope.

Unsuccessful leads:

• Cache workable tile threat status and priority per turn - seemed logical but measurements said otherwise.
• Cache underdeveloped cities - seemed logical since there are typically very few of them, but measurements said otherwise. My version distributed the Workers, though, instead of sending all of them to the same city... Could be discussed later.
• Coroutines. Require API 25 or 26, Java >= 8, Kotlin 1.5.20 and Gradle 7, but do yield acceleration by almost the number of cores. Ditched due to not wanting to tackle the synchronization problems (syncing parallel BFS access isn't so bad, other Workers suddenly blocking the way in the canReach() you're evaluating right now, that was the point I gave up on).
• The nested double BFS that is not using the BFS class: Too complicated for now. Makes up at least 2/3 of the remaining time, and caching per Worker would help as in that save every worker calls canReach an average of 6 times.

[yairm210]

Fair enough.
We can always un-cache it later if we see this causes problems.

[yairm210]

Resolve conflicts though

[SomeTroglodyte]

I'm not 100% happy with it, too many todo's, and they lead to more code review after merge and another push I couldn't resist.

But NextTurnAutomation.adoptPolicy isn't far slower than it needs to be because those preference by victory type lists get re-instantiated over and over, it's more likely the era stuff. Era names are still re-scanned from the tech tree over and over, for each getEraNumber, e.g. by PolicyManager canAdoptPolicy and isAdoptable, and it adds up - that's where I forcibly stopped myself.

[ajustsomebody]

about automate workers being the most expensive: i got a proposal for this but i have no idea how the project works, if there are 2 improvements that the workers can build and there are 5 workers first sort them by their land distance (not pathfind) to that improvement (and maybe increase the distance by 1.3 something as there are often many hills on the way) and only pathfind 2 workers (2 comes from improvement count on map) if some dont have a direct path remove it from that list, if everything is fine load them with that task and dont check other workers at all

also about city production reassignation: xlenstra said that it will be implemented by it will check for yields every turn which i think is very inefficient, i think only cities should update their yields in those cases:

• yield change due to improvement/pillage
• territory expansion
• shareable territory expansion (the tiles that dont belong to that city but that it can work)
• citadel territory steal
• improvement / tile yields change due to anything (most often techs)

[yairm210]

@logicminimal You have literally no idea how many changes are possible that would lead to a change in yield. There are definitely dozens of factors. The nice thing is, that most major changes occur over turns, not within turns. I'm completely with xlenstra on this.

[ajustsomebody]

not within turns

great improvements?