python/future.py: back out of supporting a destroy method

Exposing such a method opens up many corner cases that are hairy to deal
with.  If a user wants to shoot themself in the foot, let's not help
them.

src/bindings/python/flux/future.py

@@ -74,16 +74,6 @@ def cleanup_then(self):
     def __del__(self):
         self.cleanup_then()
 
-    def destroy(self):
-        """
-        prevent passing through to flux_future_destory via the pimpl, override so
-        that we can reset the "then handles" and cleanup the pimpl
-        """
-        # force a call to the destructor now for deterministic cleanup
-        self.pimpl.__del__()
-        self.pimpl = None
-        self._reset_then()
-
     def error_string(self):
         try:
             errmsg = self.pimpl.error_string()

t/python/t0012-futures.py

@@ -67,8 +67,6 @@ def then_cb(future, arg):
                 resp_payload = future.get()
                 cb_ran[0] = True
                 self.assertDictContainsSubset(arg, resp_payload)
-                # ensure no active watchers remain so that reactor_run returns 0
-                future.destroy()
             finally:
                 # ensure that reactor is always stopped, avoiding a hung test
                 flux_handle.reactor_stop(reactor)
@@ -78,7 +76,7 @@ def then_cb(future, arg):
         # force a full garbage collection pass to test that our anonymous RPC doesn't disappear
         gc.collect(2)
         ret = self.f.reactor_run(self.f.get_reactor(), 0)
-        self.assertEqual(ret, 0, msg="Reactor exited with {}".format(ret))
+        self.assertGreaterEqual(ret, 0, msg="Reactor exited with {}".format(ret))
         self.assertTrue(cb_ran[0], msg="Callback did not run successfully")
 
     def test_04_double_future_then(self):