reiser4: fix reiser4_post_{commit,write_back}_hook() and their invocations.

- let all hooks be called from one place (reiser4_write_logs())
- don't call reiser4_post_write_back_hook() twice
- fix reiser4_post_write_back_hook(): call the correct method of space allocator

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: make space_allocator's check_blocks() reusable.

Make check_blocks() return a boolean value (whether did the extent's
state match our expectations) instead of asserting success and crashing
system otherwise.
Also make it possible to check extents spanning multiple bitmap blocks.

The only user of reiser4_check_block() in its previous form has been updated
to assert on true return value.

Thus check_blocks() can now be reused by various parts of reiser4, e. g.
by the discard subsystem which will be added in next commits.

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: add an implementation of "block lists", splitted off the discard code.

The block list is a less memory efficient, but ordered (and thus sortable)
implementation of the same concept as the blocknr_set.

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: discard support: initial implementation using linked lists.

Implementation details:

- candidate extents are stored during the transaction to a linked list
- if an extent being added is adjacent to the last one, they are merged
  to prevent another allocation
- at commit time, the log is further sorted and extents are merged
- extents are further processed to align discard requests to erase unit
  boundaries, extending them to neighbour blocks if needed
- each erase unit is checked to be deallocated and submitted to discard
- processing stops at first failure (this does not fail atom commit)

For now (shortcomings):

- kernel-reported erase unit granularity and alignment offset are used
  as-is without any override (it may make sense in order to mitigate
  bogus values sometimes reported by kernel/hardware)
- processing each erase unit makes its own bitmap query to check
  allocation status; this is suboptimal when granularity is less than
  the block size (should not matter in practice as granularity almost
  never is that small)

Note on candidate block collection:

Another per-atom block set, ->aux_delete_set, has been added, containing
extents deallocated without BA_DEFER (i. e. blocks of the wandered
journal). When discard is enabled, storage of both delete sets is enabled.
They are stored using blocknr_lists, then spliced and sorted before
discarding, so all blocks that have been deallocated during the
transaction are considered for discarding.

Otherwise, only ->delete_set is maintained, and it is stored using
blocknr_set which is more memory efficient but inherently unordered (so it
cannot be used for the discard algorithm).

The only semantic-significant change to existing code is that
reiser4_post_commit_hook() does not clear ->delete_set (instead, it is
cleared either by discard_atom() or as part of atom's destruction). This is
OK because ->delete_set is not accessed after reiser4_post_commit_hook().

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: blocknr_list: use kmem_cache instead of kmalloc for allocating entries.

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: blocknr_set: use kmem_cache instead of kmalloc for allocating entries.

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: discard support: use reiser4_post_write_back_hook() for discarding and completing deferred deallocations.

This hook is now called after immediate deallocations in the wandered
logs code.

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: discard support: perform discard before all deallocations; simplify discard_extent().

When discard is enabled, immediate deallocations are made deferred,
and thus discard procedure takes place right before any deallocation
is made. This allows to avoid costly bitmap checks at discard time.

discard_extent() has been simplified not to check allocation status of extents
and not to do any padding of extents (as this introduces allocation races and
needs to be done properly).

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>