Test controller enhancement with new configuration options

[zzxgzgz]

This PR does the following:

• Added support for different ping modes, now user can specify whether he/she would like the pings to be executed concurrently/sequentially.
• Added support for different numbers of ports to be created in two hosts.
• Speeded up the container create process by making it concurrent.
• Added parameter to NCM's gRPC server, so that it is able to receive GoalState V2 messages in unlimited size.
• Added parameter to control whether the Test Controller should create containers and do the pings. We've been creating containers and doing pings, but disabling them(and only allowing the GoalStateV2 messages generates and sending) will be very helpful when you test with 1) A large number of ports/neighbors. 2) When you have your own way to trigger the packet_in.

Note:

The current controller has the following parameters:

Params:
1. Number of ports to generate on aca node one
2. Number of ports to generate on aca node two
3. IP of aca_node_one
4. IP of aca_node_two
5. IP of the GRPC call
6. Port of the GRPC call
7. User name of aca_nodes
8. Password of aca_nodes
9. Ping mode, either CONCURRENT_PING_MODE(0 and default), or SEQUENTIAL_PING_MODE(other numnbers)
10. Whether execute background ping or not. If set to 1, execute background ping; otherwise, don't execute background ping
11. Whether to create controller and execute pings.(0 is default and means create container and do pings; other number means NOT to create containers AND NOT to do pings).

The following is an example of using this Test Controller:

mvn exec:java -D ec.mainClass=com.futurewei.alcor.pseudo_controller.pseudo_controller -Dexec.args="number_of_ports_on_host_one number_of_ports_on_host_two host_one_ip host_two_ip ncm_ip ncm_port user_name_of_both_hosts password_of_both_hosts concurrent_or_sequential_ping background_ping_or_not whether_create_container_and_ping" -e