Revert #420 for aws

[0x2b3bfa0]

Because of reasons yet unknown to me, rclone recursive deletion code introduced with #420 is flaky:

terraform-provider-iterative/task/common/machine/storage.go

Lines 126 to 151 in d5c4d1e

	func Delete(ctx context.Context, destination string) error {
	destinationFileSystem, err := fs.NewFs(ctx, destination)
	if err != nil {
	return err
	}
	actions := []func(context.Context) error{
	func(ctx context.Context) error {
	return operations.Delete(ctx, destinationFileSystem)
	},
	func(ctx context.Context) error {
	return operations.Rmdirs(ctx, destinationFileSystem, "", true)
	},
	}
	for _, action := range actions {
	if err := action(ctx); err != nil {
	if !errors.Is(err, fs.ErrorDirNotFound) && !strings.Contains(err.Error(), "no such host") {
	return common.NotFoundError
	}
	return err
	}
	}
	return nil
	}

This pull request restores the old cloud–specific code that goes through all the objects and deletes them as part of the destroy operation.

Closes #452.

[0x2b3bfa0]

Merging this opens a follow–up technical debt issue to fix rclone flakiness for the common Delete() operation and revert this.

[casperdcl]

interesting... could you reproduce #452 consistently and does this PR fix it consistently? Trying to understand how flaky is "flaky"

[casperdcl]

repeated testing seems to show this PR (partially reverting) works, but yes please do open a follow-up issue :)

[0x2b3bfa0]

• Investigate rclone bucket emptying delay #459

[0x2b3bfa0]

I've opened an I2 (irking issue) to investigate why rclone bucket emptying finishes way after the function has returned.