[Feature]: add synchronization for Conn to make it concurrency-safe

[panjf2000]

Description of new feature

For the time being, most of gnet.Conn's methods are not concurrency-safe, which may result in some inconvenience and limitations, or performance issues like #423. Hence, I'd like to investigate the possibility of introducing the synchronization mechanism for gnet.Conn.

Scenarios for new feature

Any scenarios where gnet.Conn is required to be used in goroutines outside the event loop will benefit from this new feature.

Breaking changes or not?

No

Code snippets (optional)

What I have in mind at the moment is something like this:

type Options struct {
    ...

	// Locker will be utilized as a synchronization to ensure the concurrent safety of the gnet.Conn.
	Locker sync.Locker
}

func WithLocker(locker sync.Locker) Option {
	return func(opts *Options) {
		opts.Locker = locker
	}
}

This is just an initial idea, it's not necessarily the final implementation.

Alternatives for new feature

We can also do this internally without exposing any new APIs, which might be more straightforward but less flexiable.

Additional context (optional)

None.

[someview]

无论是读，还是写, 都可能有加锁的需求。以gnet-example中websocket为例， 由于不确定upgrade时，是否会比较消耗时间，比如需要校验token等。如果有机制能将这种操作耗时操作剥离出来，也是非常ok的事。

netpoll库是在连接级别，设置一个原子变量来实现的.

[github-actions]

This issue is marked as stale because it has been open for 30 days with no activity.

You should take one of the following actions:

• Manually close this issue if it is no longer relevant
• Comment if you have more information to share

This issue will be automatically closed in 7 days if no further activity occurs.

[github-actions]

This issue is marked as stale because it has been open for 30 days with no activity.

You should take one of the following actions:

• Manually close this issue if it is no longer relevant
• Comment if you have more information to share

This issue will be automatically closed in 7 days if no further activity occurs.