Consider dropping Freeze from the MutexArc bounds

[alexcrichton]

I see this was added as part of #7473, but I don't understand why MutexArc needs a Freeze bound for access and access_cond. I was under the impression that Freeze was just needed for safely sharing read-only data among threads, but a MutexArc only hands out one &mut T at a time, so I don't think this should be necessary.

[thestinger]

I think it was intended to prevent locking the same lock twice. I don't think consistent behaviour (one of deadlocking, recursive locking or reporting an error) can be provided when lock elision or hardware transactional memory is used as it may simply succeed due to lack of a conflict during the lock scope.

[alexcrichton]

Ah indeed, the recursive lock was the reason it was added.

[thestinger]

I don't think we'll be able to prevent recursive locking if we switch to RAII locks anyway, so we may still want to remove the bounds. It's just going to be sad to lack lock elision as it becomes more and more important. I guess we could make a separate lock type...