Evolve only if evolvable candidates no less than a certain number.

[coderplay]

Evolve only if evolvable candidates no less than a certain number.

Previously, when user configured use_lucky_egg as true, the bot will use
lucky egg even evolvale candidates is zero. That's kinda of
waste. Meanwhile, if user didn't configured use_lucky_egg, the bot will
try to evolve after sort by cp&iv, but sometimes no good potential
pokemon in that batch, it's better delay the evolution after a
while. By adding a config item evovle_num_min can cope above two
problems. The bot evolves only if evolvable candidates no less than a
certain number.

1. Evolve only if evolvable candidates no less than a certain number.
2. Dragoniar's configuration is abnormal in pokemon.json, which lack of
   "Previous evolution(s)" attribute, while the other middle-tier pokemon
   has.

[coderplay]

Also fixed some issues after: Refactor evolve_all worker #2244

1. The refactoring try to sort by pokemon index desc which is not
   good. For example, why Venusaur which is No Pokemon #3 should be with lower
   priority than Pidgey([Login] Support Google 2-Factor #16)?
2. The refactoring always use dict.get(key, {}).get(key, {}) which will
   eventually return a {} which will cause side effect. It's better
   fail fast when the dict has no attribute which is unexpected by the
   developer.
3. The reafctoring try to use cache when the pokemon is not
   evovlable. That developer doesn't know previously we didn't caculate the
   candy before evovling, thus caused a lot of failure when evovling. After
   caculating candy requirements by the refactoring and this patch, the
   failure rarely happens. Thus cache is not necessary when the pokemon is
   not evovlable.

[achretien]

Hi

1. We don't really care about priority between Pokemon 16 and 3 as they don't use the same candies. It was more about 2 and 1 which are using the same candy family. In my case I would prefer evolving 2 before 1 to get 3. Maybe we should add a flag to choose between behaviors.
2. I just did use the same method used in the other parts of the code.
3. We can effectively calculate all the possible evolutions before starting the evolution loop. I also think your method to find candy family better than mine.
4. We should make a PR with an unminified JSON file to avoid ununderstable change on this file.

[coderplay]

@achretien Thanks for your reply. With no offense, probably just different coding style. :) Let me explain more.

1. I have a further patch to automatically evolve mid-tier pokemons like Ivysaur, Metapod or Pidgeotto which have further evolution. I tried to reserve candies for mid-tier pokemons with better potential (a.k.a better iv/cp) otherwise because the basic tier pokemon like Bulbasaur, Caterpie or Pidgey will be eariler to reach the candy requirement than their upper levels. In order to avoid starvation of the upper evolution, I rely on the sort, otherwise I might need to resort it again among those pokemons in the same family. From the literal meaning of those config options of 'first_evolve_by', there is no pokemon index, right? I think just keep the literal meaning with no surprise is better.
2. For example, below code will pass an empty inventory_items if one of those key doesn't exist. It might have some side-effect to the subsequence calls.

 inventory_items = response_dict.get('responses', {}).get('GET_INVENTORY',{}).get('inventory_delta', {}).get('inventory_items', {})
evolve_list = self._sort_and_filter(inventory_items)

1. Yeah, totally agree! It's anti-human. :)