Delay Due to Cloudflare Causes `vagrant up` Failure

[utkonos]

DigitalOcean's API endpoints are protected by Cloudflare. This means if there is an issue on Cloudflare's end, the will re-route traffic adding some amount of latency. These issues are viewable on Cloudflare's status page here:
https://www.cloudflarestatus.com/

When this occurs, the public IP address is not yet populated and create.rb fails.

% vagrant up
Bringing machine 'default' up with 'digital_ocean' provider...
==> default: Using existing SSH key: otrada vagrant
==> default: Creating a new droplet...
==> default: Destroying the droplet...
/Users/username/.vagrant.d/gems/3.3.6/gems/vagrant-digitalocean-0.9.6/lib/vagrant-digitalocean/actions/create.rb:47:in `call': undefined method `[]' for nil (NoMethodError)

          env[:ui].info I18n.t('vagrant_digital_ocean.info.droplet_ip', :ip => public_network['ip_address'])
                                                                                             ^^^^^^^^^^^^^^
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/warden.rb:38:in `call'
	from /Users/username/.vagrant.d/gems/3.3.6/gems/vagrant-digitalocean-0.9.6/lib/vagrant-digitalocean/actions/setup_key.rb:31:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/warden.rb:38:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/warden.rb:117:in `block in finalize_action'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/warden.rb:38:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/builder.rb:183:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/runner.rb:104:in `block in run'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/util/busy.rb:22:in `busy'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/runner.rb:104:in `run'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/builtin/call.rb:56:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/warden.rb:38:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/builtin/config_validate.rb:28:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/warden.rb:38:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/builder.rb:183:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/runner.rb:104:in `block in run'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/util/busy.rb:22:in `busy'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/action/runner.rb:104:in `run'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/machine.rb:246:in `action_raw'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/machine.rb:215:in `block in action'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/environment.rb:649:in `lock'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/machine.rb:201:in `call'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/machine.rb:201:in `action'
	from /opt/vagrant/embedded/gems/gems/vagrant-2.4.3/lib/vagrant/batch_action.rb:88:in `block (2 levels) in run'

[utkonos]

@seth-reeser Do you have an opportunity to take a look at this problem? I submitted a PR last year that works.