We build more teams than we finally want so that we can use serverTeamRemover() actor to remove the teams
whose member belong to too many teams. This allows us to get a more balanced number of teams per server.

…first

Pick the team whose minimum team number of a server is the largest one to remove.

AddTeamsBestOf should keep building teams until each server has at least the
target number of teams.

Otherwise, simulation may time out when team remover needs to
remove hundreds of teams.

Also further speed up serverTeamRemover in simulation, and
Add comments

…false

Because serverTeamRemover takes time to remove teams,
getTeamCollectionValid() need to wait for a while before concluding that
the number of server teams is larger than the desired number.

…neTeamBudget

When a teamTracker is cancelled, e.g, by redundant teamRemover or badTeamRemover,
we should decrease the optimalTeamCount if the team is considered as an
optimal team, i.e., all members' machine fitness is no worse than unset, and
the team is healthy.

Also change some code format in self review

…ted number of teams

If the minimum number of teams of servers in a team is less than the
target value (desired_team_number_per_server * (teamSize + 1) / 2),
the team remover should not remove it. Otherwise, DD will oscillate in
building more teams and removing redundant teams.

Do not do consistency check for three_data_hall mode because when
machines are not evenly distributed across data halls, we will
need to build more teams than the total desired number to make sure
the number of teams per server is no less than the target value.

Because team remover does not remove a team if it causes 0 team per server.
So we currently disable the check until we have a better strategy to enforce the
desired number of teams.

This will not cause much problem in real situation, while having 0 team on a server
will make the server unable to host data, which is bad.