Resolve "Guard erreur 1000003 -> delete le consentement avant de jeter une erreur oauth needed"

Related to #9 (closed)

D'après la documentation GRDF (API GRDF ADICT_Messages erreurs B2B_PROD_v1.7) le cas 1000003 est sensé être renvoyé dans cette situation :

• "GRDF a révoqué votre droit d’accès aux données de ce PCE à la demande du client titulaire."

Mais après réponse d'un mail de GRDF, le code peut aussi survenir lorsqu'un problème de cache existe :

• "Après analyse, il s’agit d’un message d’erreur de Backend qui ne fait normalement pas l’objet d’un affichage auprès des Tiers. Ce dernier est en effet retranscrit sous une forme plus fonctionnelle par "Aucun droit d'accès pour tous les PCE en entrée.". Ce message d’erreur est rencontré lorsque le Tiers ne dispose pas d’un droit d’accès à l’état Actif sur le PCE pour lequel il souhaite consulter les données. Il se peut toutefois que dans certains cas exceptionnels, notre « cache » autorisant la consultation des données ne soit pas à jour entrainant un refus (à tort) lors d’une tentative de consultation des données (le message " Aucune accréditation récente trouvée." va alors s’afficher)."

Bien que le code original semble être lié au consentement, on ne peut plus jeter une erreur OAUTH_OUTDATED lorsqu'on rencontre ce code car jeter cette erreur peut bloquer l'utilisateur dans un scénario ou son connecteur lui dit que son consentement est expiré, alors qu'il est toujours actif chez GRDF.

Il a donc été choisi de mettre un code VENDOR_DOWN invitant l'utilisateur à relancer son connecteur plus tard. Si l'erreur est vraiment liée au consentement, alors l'erreur OAUTH_OUTDATED devrait être jetée le lendemain lorsque le connecteur se lancera tout seul et tentera de générer un token d'accès pour l'utilisateur.

• Lorsque grdf rencontre un problème non bloquant (ex: "2000100 - Le serveur a rencontré une erreur") ou bien l'erreur de cache "1000003" -> VENDOR_DOWN
• Lorsque l'utilisateur ne coche pas "autoriser les requêtes sur la route informatives" -> CHALLENGE_ASKED
• Exponential bounceoff pour pallier aux 429 sur onDeleteAccount()