Remove configuration section since it's out-dated and doesn't belong in an implementation details doc

Author: ReubenBond

docs/orleans/implementation/cluster-membership.md

@@ -122,45 +122,7 @@ As already mentioned, `IMembershipTable` is used as a rendezvous point for silos
 
 1. [AWS DynamoDB](https://aws.amazon.com/dynamodb/) - In this implementation, we use the cluster Deployment ID as the Partition Key and  Silo Identity (`ip-port-generation`) as the RangeKey making the record unity. The optimistic concurrency is made by the `ETag` attribute by making conditional writes on DynamoDB. The implementation logic is quite similar to Azure Table Storage.
 
-1. In-memory emulation for development setup. We use a special system grain, called <xref:Orleans.Runtime.Configuration.GlobalConfiguration.LivenessProviderType.MembershipTableGrain>, for that implementation. This grain lives on a designated primary silo, which is only used for a **development setup**. In any real production usage primary silo **is not required**.
-
-### Configuration
-
-The membership protocol is configured via the `Liveness` element in the `Globals` section in _OrleansConfiguration.xml_ file. The default values were tuned in years of production usage in Azure and we believe they represent good default settings. There is no need in general to change them.
-
-Sample config element:
-
-```xml
-<Liveness ProbeTimeout="5s"
-    TableRefreshTimeout="10s"
-    DeathVoteExpirationTimeout="80s"
-    NumMissedProbesLimit="3"
-    NumProbedSilos="3"
-    NumVotesForDeathDeclaration="2" />
-```
-
-There are 4 types of liveness implemented. The type of the liveness protocol is configured via the `SystemStoreType` attribute of the `SystemStore` element in the `Globals` section in _OrleansConfiguration.xml_ file.
-
-1. `MembershipTableGrain`: membership table is stored in a grain on the primary silo. This is a **development setup only**.
-1. `AzureTable`: membership table is stored in Azure table.
-1. `SqlServer`: membership table is stored in a relational database.
-1. `ZooKeeper`: membership table is stored in a ZooKeeper [ensemble](https://zookeeper.apache.org/doc/r3.4.6/zookeeperAdmin.html#sc_zkMulitServerSetup).
-1. `Consul`: configured as Custom system store with `MembershipTableAssembly = "OrleansConsulUtils"`.  Refer to [Consul-Deployment](../deployment/consul-deployment.md) for more details.
-1. `DynamoDB`: configured as a Custom system store with `MembershipTableAssembly = "OrleansAWSUtils"`.
-
-For all liveness types the common configuration variables are defined in `Globals.Liveness` element:
-
-1. `ProbeTimeout`: The number of seconds to probe other silos for their liveness or for the silo to send "I am alive" heartbeat messages about itself. Default is 10 seconds.
-1. `TableRefreshTimeout`: The number of seconds to fetch updates from the membership table. Default is 60 seconds.
-1. `DeathVoteExpirationTimeout`: Expiration time in seconds for death vote in the membership table. Default is 120 seconds
-1. `NumMissedProbesLimit`: The number of missed "I am alive" heartbeat messages from a silo or number of un-replied probes that lead to suspecting this silo as dead. Default is 3.
-1. `NumProbedSilos`: The number of silos each silo probes for liveness. Default is 3.
-1. `NumVotesForDeathDeclaration`: The number of non-expired votes that are needed to declare some silo as dead (should be at most NumMissedProbesLimit). Default is 2.
-1. `UseLivenessGossip`: Whether to use the gossip optimization to speed up spreading liveness information. Default is true.
-1. `IAmAliveTablePublishTimeout`: The number of seconds to periodically write in the membership table that this silo is alive. Used only for diagnostics.  Default is 5 minutes.
-1. `NumMissedTableIAmAliveLimit`: The number of missed "I am alive" updates in the table from a silo that causes a warning to be logged. Does not impact the liveness protocol. Default is 2.
-1. `MaxJoinAttemptTime`: The number of seconds to attempt to join a cluster of silos before giving up. Default is 5 minutes.
-1. `ExpectedClusterSize`: The expected size of a cluster. Need not be very accurate, can be an overestimate. Used to tune the exponential backoff algorithm of retries to write to Azure table. Default is 20.
+1. In-memory emulation for development setup. We use a special system grain for that implementation. This grain lives on a designated primary silo, which is only used for a **development setup**. In any real production usage primary silo **is not required**.
 
 ### Design rationale