resource_cloud_project: factorize serviceName discovery and manage possible domain discrepancies

[gxben]

resource_cloud_project: factorize serviceName discovery and manage possible domain discrepancies

Description

This PR aims at fixing possible race conditions on cloud project service name discovery.

Context

In some cases, when project has been created through API (Terraform here), order gets messy and despite project being fully created, some order detail items have incorrect domain associated.
(I personally ended up with 5 order details item created, 3 of them having the correct projectId set as domain and 2 of them being set with domain "*001" (i.e. considered as US project).

The current code is naively considering only the first of the detail items as a reference for the project serviceName. Chances are that, based on how items are sorted, you either get a right or bad one (i.e. US one).

Note that even if detected as US-based project, the orderDetailOperations() function calls a /me/order/{orderId}/details/{orderDetailId}/operations web service which exists in US API endpoint but not in EU one (that's not a terraform provider problem here but a real backend issue).

Fix

The PR provides 2 things:

1. Factorization of the serviceName discovery between CRUD operations
2. Loop around all order details for find appropriate EU serviceName instead of taking first index for granted and falls back to US-hack otherwise.

[gxben]

@scraly ?

[amstuta]

Hello, the code in your PR seems valid, but we are not 100% sure that it won't break anything. Would you have a reproducer that we could execute ?

[gxben]

@amstuta unfortunately that's the problem with random, depends on projects on how OVH API server returns IDs. Sometimes in the right order, sometimes not.