DLM lock and unlock functions
Introduce md_cluster_operations to handle cluster functions

This allows dynamic registering of cluster hooks.
Introduce md_cluster_info

md_cluster_info stores the cluster information in the MD device.

The join() is called when mddev detects it is a clustered device.
The main responsibilities are:
	1. Setup a DLM lockspace
	2. Setup all initial locks such as super block locks and bitmap lock (will come later)

The leave() clears up the lockspace and all the locks held.
Add node recovery callbacks

DLM offers callbacks when a node fails and the lock remastery
is performed:

1. recover_prep: called when DLM discovers a node is down
2. recover_slot: called when DLM identifies the node and recovery
		can start
3. recover_done: called when all nodes have completed recover_slot

recover_slot() and recover_done() are also called when the node joins
initially in order to inform the node with its slot number. These slot
numbers start from one, so we deduct one to make it start with zero
which the cluster-md code uses.
Lock MD super while updating superblock

This should be inter-twined with communication framework.
So, these functions will change in the future.
Use separate event counters for bitmaps

Use independent event_counter_t for each bitmap. Each is 4k long so
as to make it independent of other bitmap events.

The idea is to keep each bitmap specific to the node and not change much of the bitmap code.

0                    4k                     8k                    12k
-------------------------------------------------------------------
| idle                | md super            | bitmap super        |
| ev counter[1]       | bm[1]               | bm[1, continued]    |
| ev_counter[2]       | bm[2]               | bm[2, continued]    |
| ev_counter[3]       | bm[3]               | bm[3, continued]    |

Questions:
1. Is updating events fields enough since it represents the dynamic fields of
   the bitmap superblock?
2. Not sure of the change to filemap_get_page()

TODO:
 * Fix for archs where PAGE_SIZE != 4k
 * Fix checks with respect to file_pages exceeding page->index
 * bad block logs if required
Lock bitmap while joining
Gather resync info from other bitmap LVB

gather_all_resync_info looks superfluous here, but it would add more
code in the next few patches.

Each bitmap lock LVB stores the ongoing resync information (if any).
This helps new nodes joining in to understand which are suspended
regions. When a node joins it checks the bitmap LVBs of all the nodes
to gather resync information.

The node performing the resync writes the information on the bitmap
lockres LVB. For this, it refreshes the lock at PW. Since we already
have the lock, it should be quick to process.
bitmap_create returns bitmap pointer

This is done to have multiple bitmaps open at the same time.
Pass slot_number to bitmap_create

Slot number is now a property of the bitmap. This would enable us to read the bitmap
outside of the mddev's bitmap.

This change looks more intrusive than I thought. However, this seems necessary to read
bitmaps of other nodes.
Copy set bits from another slot
Initiate recovery on node failure

The DLM informs us in case of node failure with the DLM slot number.
cluster_info->recovery_map sets the bit corresponding to the slot number
and wakes up the recovery thread.

The recovery thread:
1. Derives the slot number from the recovery_map
2. Locks the bitmap corresponding to the slot
3. Copies the set bits to the node-local bitmap
Perform resync for cluster node failure

cinfo stores the range of suspend and this can be retrieved when
the resync thread asks for it.
This may not be necessary according to Neil: Set the RESYNC_MASK and
resync the whole range.

[BUG] On node failure, the resync happens way too fast on the node
performing "node recovery". There is something
wrong in that part of the code. sync_request is returning all
sectors as done all at once.
Communication Framework
Communication: Send functions
Reload superblock upon receiving METADATA_UPDATE

Update is deferred to a thread. This may be wrong. It should be done
before releasing ACK.
Send suspend/resync-finished while performing resync
Suspend/Resync Finished action

When a SUSPEND_RANGE message arrives, the node removes the entry
with the current slot number(though none should exist) and adds
the range to the suspend_list.

Simlarly, when a RESYNC_FINISHED message is received, node clears
entry with respect to the bitmap number.

Should we call this RESYNC_START and RESYNC_FINISHED for better
correlation?
Suspend writes in RAID1 if within range

If there is a resync going on, all nodes must suspend writes to the
range. This is recorded in the suspend_info/suspen_list.

If there is an I/O within the ranges of any of the suspend_info,
should_suspend will return 1.