[WIP] Fix race in DataChannel.open()

[enobufs]

Now it uses write lock in this PR.
No regression in unit tests, race detection nor golangci-lint in my local run.

I noticed the was a race (reported as #509), not caused by this modification.

Resolves #505

[coveralls]

Pull Request Test Coverage Report for Build 2476

• 2 of 4 (50.0%) changed or added relevant lines in 1 file are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.04%) to 80.452%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
datachannel.go	2	4	50.0%

Files with Coverage Reduction	New Missed Lines	%
lossy_stream.go	2	81.13%

Totals
Change from base Build 2466:	-0.04%
Covered Lines:	4091
Relevant Lines:	5085

---

💛 - Coveralls

[Sean-Der]

Can you make this so we just take the writelock for setting d.ReadyState I just don't want to be wasteful having a write lock for the whole function. If this is a bad idea please push back!

d.mu.RUnlock()
d.mu.Lock()
d.ReadyState = DataChannelStateOpen
d.mu.Unlock()

[enobufs]

I think, it wouldn't give us much because:

1. This method would virtually 100% succeed in production use (write lock will be held in most of times).
2. Sticking with only one kind of lock is relatively less error-prone.
3. DataChannel.open() won't be called that often anyway (I wouldn't worry)

[Sean-Der]

A agree with all that, I was overthinking it. More complicated code for no real gain :)

[Sean-Der]

LGTM! Great catch here :)