handle cases where notify does not need to be sent

[joel-bluedata]

If a member is deleted before it ever got out of create pending state, we don't need to (and therefore don't) send a delnodes notification to ready nodes, although we do update their configmeta.

A fairly common way to trigger this: ask for more members than can be placed in the current cluster (because of resource limitations), then realize the problem and reduce the number of members.

In the new reconciliation process since PR #272, this process is broken. The kdcluster will never return to a stable configured state even when the pending members are removed.

We need to change syncMemberNotifies to go ahead and make sure that lastSetupGeneration is up-to-date for a ready member who has no notifies queued to send.

Kartik is already doing this in PR #283 since he's dealing with another instance where we have changes to reconcile but no notifies to send; it's the first little block added to members.go in that PR. I'm mentioning it here because it's something we need to fix regardless of when PR #283 goes in.

It looks like issue #273, which involves skipping notifies, would also need this.

[joel-bluedata]

Might want to think about doing an 0.4.1 bugfix release.

[joel-bluedata]

Will fix this in a 0.4.1 release and then merge to master.