L'ancien code ne passe pas à l'échelle en fonction du nombre d'éléments
présents dans GLPI. En effet, on récupère tous les ordinateurs et tous les
équipements réseau. Pour chaque, on lance 2 requêtes (récupération IP et tags).
On fait des traitements simples et enfin, on ajoute. Évidemment, il faut
également prendre en compte le formatage/parsing SOAP qui n'est pas super rapide.

Solution :
  - déporter le travail en une seule fois sur le SGBD qui est conçu
pour ce type de travail ;
  - exporter le minimum d'informations ;
  - utiliser webservices uniquement pour le formatage SOAP des données
exportées.

Implémentation : une nouvelle méthode listObjectMonit() spécifique à notre
usage dans le plugin webservices de GLPI. Elle fait une requête SQL qui retourne
uniquement les informations utiles (nom, IP, tags) à Centreon en une seule fois.
Il faut également adapter Centreon-GLPI à ce changement.

Les machines (équipements réseau et ordinateurs) et une liste de tags sont
remontées depuis l'inventaire GLPI. Chaque tag de la liste est en fait
le nom d'un template existant dans Centreon qu'il faut ajouter à la machine.

L'extension Webservices de GLPI ne propose plus de méthode getNetworkEquipment().
Cette méthode était utilisée au seul but de remonter l'adresse IP de
l'équipement réseau. Nous utilisons getNetworkports() à la place. Nous vérifions
que l'adresse IP remontée est valide. Nous refusons désormais d'ajouter un
équipement réseau qui n'a pas une adresse IP valide.

Par défaut, la méthode methodListObjects() retourne 20 résultats. Le client,
centreon-glpi dans notre cas, peut passer un paramètre pour changer cette
limite. Comme centreon-glpi ne faisait rien, cela nuisait aux tests.
Maintenant que c'est réglé du côté centreon-glpi aucune raison de laisser
ce patch crade. Annule l'autre moitié du commit
be8ce666

Note : la methode methodListObjects() a été patchée en upstream. Le
pseudo-patch du commit be8ce666 est
donc inutile.