Implement sync

[niaow]

This is based on top of #828 and adds full support for the sync package, implementing blocking by using the internal/task package.

[niaow]

I have implemented most of sync, and I am not quite sure how to test this kind of stuff.

[deadprogram]

Do you mean usage testing? If so then I can give this a try in the mqtt code we have that could really use a mutex.

[aykevl]

Yeah not sure how to best test this either. The happy flow should already be mostly tested in testdata/channel.go, and that is the only thing that's easy to test. It's hard to prove the non-existence of a concurrency bug. Some more real-world testing would definitely help build confidence, though!

[aykevl]

I have some questions about the sync.Cond design. Maybe I misunderstood something but it doesn't seem sound right now. See my comments below.

The other commits look good to me (although I haven't tested them).

[niaow]

CI had failed because of the issue described in #977, so I rebased on dev.

[aykevl]

Looks good to me. However, some more testing would be good to have. @deadprogram you mentioned you might have some code with which you could test this?

Also, you could add some tests to ./testdata/coroutines.go to check that at least the happy path works. Something along the lines of:

// one goroutine
var l sync.Mutex
go unlocker()
l.Lock() // should suceed
println("mutex locked for the first time")
l.Lock() // should block until unlocked by the other goroutine
println("mutex locked for the second time")

// another goroutine
func unlocker() {
    l.Unlock()
    println("mutex unlocked...")
}

[niaow]

@aykevl I added a test as requested.

[aykevl]

Thanks a lot!

I have merged this without squasing because there were various commits that really were different features, although there were also some that might have been better squashed together with some other commit (such as the last one). I didn't want to lose that history.