st.c: retry operations if rebuilt

	Calling the .eql? and .hash methods during a Hash operation can
	result in a thread switch or a signal handler to run: allowing
	one execution context to rebuild the hash table while another is
	still reading or writing the table.  This results in a
	use-after-free bug affecting the thread_safe-0.3.6 test suite
	and likely other bugs.

	This bug did not affect users of commonly keys (String, Symbol,
	Fixnum) as those are optimized to avoid method dispatch
	for .eql? and .hash methods.

	A separate version of this change needs to be ported to Ruby 2.3.x
	which had a different implementation of st.c but was affected
	by the same bug.

	* st.c: Add comment about table rebuilding during comparison.
	  (DO_PTR_EQUAL_CHECK): New macro.
	  (REBUILT_TABLE_ENTRY_IND, REBUILT_TABLE_BIN_IND): New macros.
	  (find_entry, find_table_entry_ind, find_table_bin_ind): Use new
	  macros.  Return the rebuild flag.
	  (find_table_bin_ptr_and_reserve): Ditto.
	  (st_lookup, st_get_key, st_insert, st_insert2): Retry the
	  operation if the table was rebuilt.
	  (st_general_delete, st_shift, st_update, st_general_foreach):
	  Ditto.
	  (st_rehash_linear, st_rehash_indexed): Use DO_PTR_EQUAL_CHECK.
	  Return the rebuild flag.
	  (st_rehash): Retry the operation if the table was rebuilt.
	  [ruby-core:85510] [Ruby trunk Bug#14357]

	Thanks to Vit Ondruch for reporting the bug.

	From: Vladimir Makarov <vmakarov@redhat.com>

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_5@62858 b2dd03c8-39d4-4d8f-98ff-823fe69b080e