fix(access): updates no longer mistakenly blocked in some scenarios

In order to fix `canEdit()` in 1.9, `update()` needed to load a fresh copy of
entity from the DB to check the persisted attributes. In that fix,
66eb9e6,
a corner case was checked out of my paranoia that a dev would load an
invisible entity with access control on, but try to delete it with access
off.

I now believe this check was unnecessary (we never did similar checks for
`delete()`). When the original `canEdit()` attributes issue was resolved in
#9434, I should've made this change.

engine/classes/ElggEntity.php

@@ -1592,12 +1592,6 @@ protected function update() {
 
 		_elgg_services()->boot->invalidateCache($this->guid);
 
-		if (!has_access_to_entity($this)) {
-			// Why worry about this case? If access control was off when the user fetched $this, but
-			// was turned back on again. Better to just bail than to turn access control off again.
-			return false;
-		}
-
 		if (!$this->canEdit()) {
 			return false;
 		}