Revert "FAST: Fix uninitialized variable"

This reverts commit 57979f0d2888819b14b1df4f003b355756519e15. It clashes with
Marat's FAST index map patch.
FAST: Do not use index maps to search fast fields

Preamble: Every FAST message has a set of associated
fields. So far this set presents a simple linear array.
When a fast message is processed (e.g. to reconstruct
order book dynamics) one has to manipulate with fields
by exploring their values. In order to prevent inspecting
the whole array of fields we can use the FAST specific
advantage, namely the order of fast fields can be obtained
from a template file in advance. We used this fact to
manipulate with Snapshot and Incremental messages (see
msg_map and md_map data structures and map_field() function).

This patch claims that we should abandon the aforementioned
logic for three main reasons:

* FAST template usually defines many types of
Incremental and Snapshot messages
(e.g. ftp://ftp.cmegroup.com/fix/Production/Templates/Active/templates.xml)
Generally speaking, each incremental or snapshot message
has its own field order. Hence, we should maintain index
maps for each type of snapshot and incremental messages.
This seems to be quite inflexible: firstly, we have to
construct additional data structure to manage such maps,
secondly, we can map the predefined fast field types only,
thirdly, such design makes difficult to support it
accross the venues.

* The main reason of why we are using index mapping is
the original way we store fast fields inside the fast
message. So far, it was a simple linear array which does
not allow us neither perform advance search nor use
FAST specific details. Hence, we should not struggle
with the consequence of such poor design but to change
such design.

* Order books reconstruction is not the only place where
fast messages are explored. Hence, we should not
develop a specific solution whenever we need it.
Instead, a generic way should be provided (fast_message
specific but not fast_book specific).

To sum up, this patch suggests that we should use
the generic way to handle fast_fields (sequential
search in case of linear array). Any advanced
technique has to be generic and should be developed
in the future (if needed, of course).

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>