Remove a stale comment

buf_LRU_block_remove_hashed(): Remove a comment that had been added
in mysql/mysql-server@aad1c7d0dd8a152ef6bb685356c68ad9978d686a
and apparently referring to buf_LRU_invalidate_tablespace(),
which was later replaced with buf_LRU_flush_or_remove_pages() and
ultimately with buf_flush_remove_pages() and buf_flush_list_space().
All that code is covered by buf_pool.mutex. The note about releasing
the hash_lock for the buf_pool.page_hash slice would actually apply to
the last reference to hash_lock in buf_LRU_free_page(), for the
case zip=false (retaining a ROW_FORMAT=COMPRESSED page while
discarding the uncompressed one).

storage/innobase/buf/buf0lru.cc

@@ -1186,25 +1186,6 @@ static bool buf_LRU_block_remove_hashed(buf_page_t *bpage, const page_id_t id,
 			return true;
 		}
 
-		/* Question: If we release hash_lock here
-		then what protects us against:
-		1) Some other thread buffer fixing this page
-		2) Some other thread trying to read this page and
-		not finding it in buffer pool attempting to read it
-		from the disk.
-		Answer:
-		1) Cannot happen because the page is no longer in the
-		page_hash. Only possibility is when while invalidating
-		a tablespace we buffer fix the prev_page in LRU to
-		avoid relocation during the scan. But that is not
-		possible because we are holding buf_pool mutex.
-
-		2) Not possible because in buf_page_init_for_read()
-		we do a look up of page_hash while holding buf_pool
-		mutex and since we are holding buf_pool mutex here
-		and by the time we'll release it in the caller we'd
-		have inserted the compressed only descriptor in the
-		page_hash. */
 		hash_lock->write_unlock();
 
 		if (bpage->zip.data) {