FAST: Do not use states explicitly outside the library

An application which is using libtrading FAST functionality
must not use FAST states explicitly. Moreover, essentially
it should not know about states at all because they are
implementation details which are to be hidden from others.

Instead, every application should use interface provided by
the library. For example, before sending or receiving a
message it should be initialized by fast_message_init().
If a FAST server would not like to transfer an optional
field, it should use field_set_empty() to let the library
know that a particular field is not present in an outcoming
message.

To achieve the aforementioned goal the patch slightly modifies
the testing suite implementation internals. Messages that are
to be sent/received are stored in a container with reference
numbers starting from 1. Zero element is used to store a "pure"
message i.e. a message which is based on a particular template
and which is initialized via fast_message_init. We need such a
message to correctly bind a template with an open fast session.
These manipulations are essential for delta operator.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Fix delta operator problems while receiving a message

The patch was originally created to fix two problems while
a message is being received (Delta operator only):

a) For all numeric data types the delta which is being
transfered is always of type Signed Integer but fast_decode_uint()
now assumes it being Unsigned Integer which obviously lead to bad
consequences

b) It is possible to receive an optional field with delta operator
applied with absent value. In such a case FAST_STATE_EMPTY should
be set. Our code do not allow such a possibility at the moment.
The patch should fix this flaw.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: Fix delta operator problems while transferring a message

The patch was originally created to fix two problems while
a message is being transfered (Delta operator only):

a) For all numeric data types the delta which is being
transfered is always of type Signed Integer but fast_encode_uint()
now assumes it being Unsigned Integer which obviously lead to bad
consequences. Fix a function in a way to transfer Signed Integer
if a particular field has Delta operator applied.

b) Delta Operator assumes that delta is always present in a stream.
This means that Delta Operator encoding should always end with
transfer being made. Encoding functions must not return until
something is pushed into the stream. Fix all encoding functions.

Moreover, this patch slightly adjusts the code to make it easier
to read. The idea is that optional and mandatory fields are
handled in a similar way while being encoded except for a few
optional-specific cases. So the code is amended in a way to
get rid of undesirable 'if'-branches i.e. to arrange it in a
plain manner.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: clean encoding functions' code

The message that is in an undefined state (before anything
is transferred) must move to another state once the first
message goes out (either to assigned or empty states). It
must not leave in an undefined state.

This patch slightly adjusts the code to make it easier to read.
The idea is that optional and mandatory fields are handled in a
similar way while being encoded except for a few optional-specific
cases. So the code is amended in a way to get rid of undesirable
'if'-branches i.e. to arrange it in a plain manner

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
FAST: For each operator a new test case file is added

For each possible operator a new test case is added.
So, there are files for the followings operators:
None, Copy, Increment, Delta, Constant. Each file
contains fields of all supported types i.e. integer,
unsigned integer, decimal and string and of all
possible presence values i.e. mandatory and optional.

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