helper/schema: Rename Timeout resource block to Timeouts
- Pluralize configuration argument name to better represent that there is
one block for many timeouts
- use a const for the configuration timeouts key
- update docs
the terraform package doesn't know about TestProvider, so don't put the
hooks in terraform.MockResourceProvider. Wrap the mock in the test where
we need to check the TestProvider functionality.
Fixes: #12506
When a replication_task cdc_start_time was specified as an int, it was
causing a panic as the conversion to a Unix timestampe was expecting a
string
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAwsDmsReplicationTaskBasic'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/03/08 22:55:29 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAwsDmsReplicationTaskBasic -timeout 120m
=== RUN TestAccAwsDmsReplicationTaskBasic
--- PASS: TestAccAwsDmsReplicationTaskBasic (1089.77s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 1089.802s
```
Always wait for watchStop to return during context.walk.
Context.walk would often complete immediately after sending the close
signal to watchStop, which would in turn call the deferred releaseRun
cancelling the runContext.
Without any synchronization points after the select statement in
watchStop, that goroutine was not guaranteed to be scheduled
immediately, and in fact it often didn't continue until after the
runContext was canceled. This in turn left the select statement with
multiple successful cases, and half the time it would chose to Stop the
providers.
Stopping the providers after the walk of course didn't cause any
immediate failures, but if there was another walk performed, the
provider StopContext would no longer be valid and could cause
cancellation errors in the provider.
Andy Lindeman