les: protect field access with lock to avoid possible data race

[BurtonQin]

Fixed inconsistency and also potential data race in les/client_handler.go and les/clientpool.go:
e.g. In les/client_handler.go:
p.headInfo is read/written 11 times in les/peer.go and les/fetcher.go; 10 out of 11 times it is protected by q.lock.RLock()/Lock(); 1 out of 11 times it is read without a Lock, which is in func handle() on L128.
A data race may happen when handle() and other func like announce() are called in parallel.
The fix is to protect the access to p.headInfo and save the result to a local variable.
I am not sure if announce(p, headInfo) will have an atomicity violation after this fix.

A similar bug is an unprotected access to f.capLimit in setCapacity() in les/clientpool.go.
I wonder if this function has some special calling guarantee to avoid data race on f.capLimit, since all other functions protect the field with f.lock.Lock().

See #20651

[rjl493456442]

I think like the entire setCapacity function should hold the lock before we access some sensitive data. It's changed in the new clientpool.

[fjl]

These issues will be fixed in the next protocol version. We don't want to add the changes now because they will cause a rebase conflict with the new code.