Bug #83376 Fix for 19218794 didn't cleanup workarounds in dict_mem_create_temporary_table()

Description:
Commit https://github.com/mysql/mysql-server/commit/de3210fdae9938eb95691fada9c58a2959bae7fb introduced reasonable solution for stale InnoDB tablespaces.

However it didn't cleanup old workarounds that were supposed to reduce probability of the same problem, specifically changes to dict_mem_create_temporary_table() don't seem to be of any value anymore. See:
https://github.com/mysql/mysql-server/commit/a90439b7724b7839b97b967ca302cb9c833869e9
https://github.com/mysql/mysql-server/commit/887aebeb4ac41c78bbc590cb9ee110a6e2452440

The latter change is especially problematic:
- even though it is out of hot path, it adds heavyweight full memory barrier (whereas relaxed memory order is enough) along with heavyweight atomic read-modify-write without any good reason
- it also updates shared variable (potential scalability bottleneck) whereas code is supposed to generate name for a temporary table (which is thread local thing)
- there is harmless race condition: multiple threads may get same "randomly distributed number" because there's a gap between dict_temp_file_num increment and time when it is actually used

How to repeat:
No user visible effect yet. See dict_mem_create_temporary_tablename().

Suggested fix:
Revert changes to dict_mem_create_temporary_tablename() introduced by forementioned revisions.

Sergey,

I have analyzed thoroughly, both the fix and the workarounds. I think that you are right that workarounds are not needed, but I do not find the second patch so drastically inhibiting as you described.

However, I do agree with S3 severity.

Verified.

Sinisa, thanks for prompt reply! You're right. I should've noted that the second change doesn't seem to be inhibiting at the moment, but has potential to become such.