Reuse Large Buffers in MigrateSession

[vazois]

This PR tries to improve memory utilization and reduce fragmentation by reusing large buffers that were allocated across different migrate sessions.
The PR includes the following:

• Augment the network stack to support using separate send and receive buffer size allocation by providing separate buffer pool objects
• Declare a shared NetworkBuffers object in MigrationManager and ReplicationManager in order to re-use allocated buffers across different scenarios.
• Utilize the shared NetworkBuffers object to allocate buffer space for managing keys that actively being migrated.
• Added PURGEBP command. Issuing PURGEBP [MM|RM] will attempt to release any buffer not being used in LFBP of the migration manager or replication manager.
• Added INFO BPSTATS to list information about the shared buffer pool of the migration and replication managers.

Notes:

• There is an upper limit on the number of entries per level in the LimitedBufferPool which may cause fragmentation of the LOH due to the way we allocate and return buffers to the pool itself (shown below)

  garnet/libs/common/Memory/LimitedFixedBufferPool.cs

  Lines 55 to 61 in 68a7a85

  	if (Interlocked.Increment(ref pool[level].size) <= maxEntriesPerLevel)
  	{
  	Array.Clear(buffer.entry, 0, buffer.entry.Length);
  	pool[level].items.Enqueue(buffer);
  	}
  	else
  	Interlocked.Decrement(ref pool[level].size);

  The default limit is 16 entries which should be enough for common scenarios (i.e. up to 16 parallel migrate sessions and up to 16 replication sessions).

• Separate buffer pool from send and receive spec.

• Remove unused parts of NetworkSenderBase.

• Resize allocation for send/receive of replication code.

[badrishc]

no need to explicitly call out "private" members in the codebase.

[badrishc]

This struct does not do much, can create challenges with single-copy as it is a struct with value semantics, creates another level of indirection everywhere, and generally pervades across the codebase. The main thing it does is to use two allocation sizes, which can be maintained by callers or within LFBP itself.

[badrishc]

See comments.

[badrishc]

It can be dangerous to call potentially mutating methods (purge sounds mutating, although its implementation here is safe as it probably passes through into the LFBP class). As this could be a potential copy of the struct, it can create subtle bugs, as well as correctness and maintenance challenges.

[badrishc]

can't really reliably dispose structs.