Corrects an issue where for the hour after the DST transition, the
local UTC offset was listed.  The UTC offset was the DST offset
instead of the standard time offset.

The runtime library captures this an ambiguous time.  That is
the local time that occurs twice - once in DST then once in standard
time.  If DST is an extra 1:00 a.m. offset and ends at 2:00 a.m., 1:00 a.m.
to 1:59:59.9999.... occurs twice.  First in DST then again in standard
time.

The classlibs had this incorrect - they did not consider 1:00 a.m. an
ambiguous time, and considered 2:00 a.m. ambiguous.  However it should
be reversed.  1:00 a.m. occurs twice, but 2:00 a.m. only occurs once.
The instance we would hit 2:00 a.m. DST, we instantaneous switch to
1:00 a.m. standard.

The classlibs were also not recording enough information to record
which side of DST a local time was.  When converting a time from UTC,
or using DateTime.Now an internal flag, IsAmbiguousDaylightSavingTime,
should be set if the time is an ambiguous local time that is on the
DST side of the transition.  The classlibs were calling
TimeZone.IsAmbigousTime which has a wider defintion for ambiguous
time that the IsAmbiguousDaylightSavingTime should have.  It returns
true for local times on either side of DST.  So a new method
IsAmbiguousLocalDstFromUtc was added to check this case.

The classlibs were also not checking the IsAmbiguousLocalDstFromUtc
flag when getting the UTC offset for a local time.  So a check
was inserted in two locations to correct for that.

Some tests has to be updated to reflect these new definitions of when
DST starts and ends and which times are ambiguous.  These also account
for some test changes required by cherry-picked changes to
TimeZoneInfo.cs where the corresponding test changes were not
cherry-picked.  Some of those changes where in PR's that updated to
the CoreFx TimeZoneInfo class.

All these changes have been verified against the behavior of the
.Net Framework and they match.

Fix case 1288231:
Mono: Fix incorrect UTC offset during daylight savings time transitions

Addresses an issue with jumping into DST for some time zones when the incorrect date-time offset is returned for date-time in UTC (which comes from DateTime.Now). The fix is to just check if the incoming date-time is in UTC.

Also added a set of tests for some time zones to verify jumping into DST in general.

Fixes https://github.com/mono/mono/issues/16395

Fixes https://github.com/mono/mono/issues/16742

When a datetime appears in range of [end_of_DST_period - Daylight_delta; end_of_DST_period] it's not DST and should return base offset.

Fixes #9664.

There is a small race condition during the completion of a native thread join
call. During that period of time the tid is no longer included on the
internal list tracking joinable threads so a thread that will join on the
tid while another thread (like the finalizer thread) is waiting on native
join to complete for the same tid, will cause the managed Thread.Join call
to complete before the native join call has completed. This race could cause
issues on some OS:es that clear's up some thread resources, like abandoned
mutexes when the thread has exited. This race is hit by WaitAnyWithSecondMutexAbandoned
since the call to Thread.Join will return before the thread owning the mutex
has terminated meaning that it doesn't get ownership of the abandoned mutex
as assumed by the test.

Fix makes sure Thread.Join won't complete until native thread join is complete.
Increasing the join timeouts in the test also eliminates a timeout error making it
harder to hit the problematic code path, primarily during reproduction
in the debugger.

Fix also switch to coop mutex for joinable threads.

2020.2 : Unity master fix case 1273662 

Remove hack from mono_free_method. Bypassing cleanup here was causing corruption to persist in mscorlib's method hashtable when a rehash occurred.  Unity profiler may need changes to avoid possessing dangling pointers. Same with the mono profiler (as the comment indicates)

https://github.com/Unity-Technologies/mono/commit/7869333c52a2fc2d165effefdbbe97fdf9587b57
https://github.com/mono/mono/pull/9863
https://github.com/Unity-Technologies/mono/commit/f265d9a7838c97d33e8836dfc42d1f946de09041

Needed in order to fix corruption that was occuring to mscorlib's image table on domain reload due to dynamic methods from other images being stored in a hashtable that was not being cleaned up on domain reload.

Ensure special static slots respect alignment (case 1266322)

Without proper alignment, this may lead to reference types
being stored at non-pointer aligned offsets. Among other
issues this may lead to the GC not scanning those pointers
properly.

Sign binaries after lipo-ing them since lipo drops signature added by the linker. Also, use JIT entitlement for signing executables.

https://github.com/mono/mono/pull/5599 fixed a race condition during shutdown
when runtime threads have come parts of their way through detach, but still
depend on runtime resources, like GC memory. The fix added runtime threads
to the joinable thread list just before they vanished from mono_thread_manage
radar making sure shutdown waited upon the thread before cleaning up.

The above fix slightly changed the behavior of the finalizer thread since it
waits on joinable threads and will now potential block on threads still
executing code (that involves runtime resources). There’s was an assumption
around the threads on the joinable thread list that they should be very close
to complete when added, so join calls coming from the finalizer thread should
almost never block and if it does, the code that remains to execute should not
involve runtime operations risking deadlock situations. Adding the thread to
the list earlier than previously done expose the shutdown to some potential
theoretical problems.

To mitigate the risk and still solve the race condition this commit adds a
mechanism to keep track of active runtime threads until they park on joinable
thread list. The pending counter will be waited upon by the shutdown
thread, just before it does its regular wait on all joinable threads
(after finalizer thread has stopped) to make sure all runtime threads have
been added to the joinable thread list before waiting upon them. Threads are
added to the joinable thread as late as possible, exactly how it’s been done
in the past by sgen_client_thread_detach_with_lock. Shutdown thread will wait
on runtime threads to appear on the list for a short time and if timeout (pending
runtime thread count not reaching 0 before timeout), it will just print a warning
and continue shutdown.

Getting into a wait state during shutdown due to runtime threads not yet added to
joinable threads list should be very rare (hitting previous race condition that was rare),
triggering the timeout should be even more rare, and if that ever happens, we are exposed
to shutdown race condition as we have had in the past, but now we at least get a warning in
the log making it simpler to analyze further.

This commit also fixes a problem with the debugger thread hitting the same race condition as above.
The shutdown thread stopping the debugger thread didn't completely wait for it to stop using runtime
resources before continue shutdown sequence. This triggers the same race condition as when shutting
down regular runtime threads. This commit makes sure stop_debugger_thread waits on the debugger thread
handle to become signaled (happens at the very end of thread lifetime) before continuing the shutdown
logic.

* Generalize commit 0c6932a9 to support LDARG{0|1|2|3}, LDLOC{0|1|2|3}, LDARGS, LDLOCS, LDARG and LDLOC instead of LDLOC and LDLOCS. Improves generated code similar to issue #60945

Merge pull request #1335 from Unity-Technologies/unity-master-method-to-skip-assembly-version-validation

Add option to ignore versions when loading strong named assemblies

Fixing an issue with ManagedWebSocket 

Reintroduce https://github.com/Unity-Technologies/mono/commit/6c41f64f25da4c12b237b6bb51765722e0dd5281#diff-0ff844e784e15d2542b71c85d2c0133e

This is so we will not get errors when resolving strong named assemblies for a version not loaded.
This option will ignore the version

https://forum.unity.com/threads/current-netstandard-2-0-system-net-websocket-clientwebsocket-has-a-critical-bug.785366/

Fix handling invalid Windows proxy config

source: https://github.com/mono/mono/pull/12595

Re-adding whitespace to reduce diff noise and make future cherrypicks easier.

[debugger] Access invalid memory address using PointerValue Command. …

* Validate the address that came from IDE using PointerValue. The IDE can send an invalid address and it was crashing mono.

Fixes #18191
Fixes #15612
Co-authored-by: NAleksey Kliger (λgeek) <akliger@gmail.com>

Wrap create_file_to_check_memory_address in #ifndef _MSC_VER check as it's only used in that scope.

Fix random crash on OSX when pushing thread stacks

Fixing hang that would occur when a Debugger.Break would be triggered…

Fixing hang that would occur when a Debugger.Break would be triggered while we are already processing a breakpoint. (case 1254123)

Adding test for debugger hang fix to case 1254123

Added a new property to Tests class which breaks this test.

[corlib] Use Environment.Platform to access the platform, rather than…

[corlib] Use Environment.Platform to access the platform, rather than probing the file system (#6535)

Alternatve patch to: #6533

Update pip install index-url

Unity master update pe verifier