This PR refactors the code used to poll a Droplet's status after the request to create it. #767 points out one issue with the existing implementation, but it also exposes another issue with it. So I've taken the opportunity to fix those and make the entire process more efficient.

It now first uses waitForAction to ensure that the Droplet create action completes successfully. This allows us to fail fast in the case of a real error instead of continuing to poll the non-existent Droplet. Polling the action endpoint allows for an error to be reported while polling the droplet endpoint just 404s (which we retry on) if the create fails.

The call to waitForDropletAttribute checking for the Droplet's status attribute to move from new to active is still made after that. This is possibly unnecessary, but I've kept it to make sure we don't introduce any unexpected behavior changes. (I'm not 100% positive that the action completing is entirely equivalent to the Droplet becoming active.)

It also removes the usage of resourceDigitalOceanDropletRead in dropletStateRefreshFunc in order to reduce the overall number of API calls made. Currently in main, each pass through newDropletStateRefreshFunc actually calls client.Droplets.Get twice. The final call in resourceDigitalOceanDropletCreate to resourceDigitalOceanDropletRead is also removed to cut another redundant API call.

So while this now makes calls to both the actions and droplets endpoints to make sure the Droplet has been successfully created, it is still more efficient and reduces the overall number of API call made substantially.

Additionally, there are a number of unrelated fixes to the Droplet acceptance tests so that they all now pass. These failure seem to be the result of moving the tests from using legacy Droplet plans to new ones without updating the expected disk sizes.