More robust AAE repair

Since AAE tree building is async there are scenarios where an object
is deleted, the Yokozuna hashtree knows it is deleted but KV doesn't,
repair is invoked, but the KV object has already been deleted.  Thus
you can't rely on `get` to return an object.  Futhermore, other error
tuples could be returned but that shouldn't cause the exchange FSM to
crash with `badmatch`.  Instead just ignore it and let the a future
exchange retry the repair if it is still needed.