Scaling up gobgp, handleFSMMessage re-entrant

[nplanelcisco]

This PR will enable handleFSMMessage function to be re-entrant, this will allow peers to run in parallel
Notes:
o adj tables are accessed under s.shared.Lock()
o I ran some benchmark and fuzzing adding/delete peers and path dynamically under -race

Plan:
I let this PR as draft as it missing
o a concurrent manager.Table.Update() race unit tests
o some benchmark results

[fujita]

I think that adding RWMutex to destination consumes too much memory. If we enable concurrent access to a table, sharding would be an option.
Making handleFSMMessage read lock needs more work. For example, stopNeighbor() manipulates neighborMap.

[nplanelcisco]

I think that adding RWMutex to destination consumes too much memory. If we enable concurrent access to a table, sharding would be an option. Making handleFSMMessage read lock needs more work. For example, stopNeighbor() manipulates neighborMap.

Thank you,
o fixed the stopNeighbor() by calling it under write lock
o limited the number of destination mutex by allocating lock bucket based on NLRI
o adding some FSM Handler race tests
o made EVPNMacNLRIs thread safe