Same operations were performed in `process_input_ds()` and
`get_output_ds_info()`; now they are collected under the name
`get_ds_info()`, while all the input/output DS type related operations
are left to `process_*_ds()`.

If single dataset record does not contain enough information to
construct service fields for ES indexing, it does not mean that all the
datasets should be skipped.

Changes in error handling.
1. If Rucio returns `DatasetIdentifierNotFound`, set `deleted` to
   `True` (previously was treated as any other `RucioException`).
2. In case of `RucioException` mark message as "incomplete" -- this
   record will be written to ES in "update" mode, not "insert"
   (previously `deleted` and `bytes` would be set to `True` and `-1`).
3. If some of required fields can not be extracted from Rucio (or have
   value `null`), they are left unset (previously would be set to
   `None`.
4. If in the result message some fields of those that were supposed to
   be added at this stage are missed, the message is marked as
   `_incomplete`.

What is not good in this logic: if dataset was removed from Rucio, it
will always be marked as "requiring update". But for now we have only
this option: to use "update" instead of "insert", we need to know that
the message is incomplete; and when the message coming to Stage 019 is
incomplete -- it should be marked as "requiring update" for further
investigation.

Maybe the logic could be extended and "_incomplete" should be turned
into two different markers: "update since the original source removed
useful data" and "update since we failed to connect to the original
source", but... not now.

```
2020-03-05 19:28:04 (DEBUG) (ProcessorStage) Traceback (most recent call last):
(==)   File "<...>/ProcessorStage.py", line 231, in run
(==)     if msg and process(self, msg):
(==)   File "<...>/091_datasetsRucio/datasets_processing.py", line 233, in process_input_ds
(==)     data.update(ds)
(==) UnboundLocalError: local variable 'ds' referenced before assignment
```

`/Utils/Dataflow/test/utils/compare_ndjson_files.py` shows changes like these:

```
Record seem to differ for uid=mc15_13TeV.387007.MGPy8EG_A14N_BB_direct_300_295_MET100.merge.AOD.e3994_a766_a821_r7676_tid08124406_00
key = deleted:
Items missed in (2):
(1) False
Items missed in (1):
(2) True
Item missed in (2): 'bytes'
Item missed in (2): 'events'
Key missed in (1): '_incomplete'
```

...which means:
* DS with given uid was removed ('deleted: True');
* fields 'bytes' and 'events' are not presented in the new record;
* key '_incomplete' is added.

So when this record gets to the 019 (esFormat) and 069 (upload2es), it
will be written in the "update" mode: 'bytes' and 'events' won't be
changed, 'removed' will be set to True, and '_update_required' will be
set to True.

The latter may be not the best option, but it is the only flag we have
right now to say that there's something wrong about given record... and
here "wrong" is that Rucio did not provide us with the information we
needed.

When the stage fails to load `rucio.client` module, it does not stop the
execution -- for in case of `--skip` opotion specified we do not
actually need the module to go on.

The script exits only when tries to initialize the client -- but since
the initialization occures within `try/except` clause, it first stumbles
over the expected exception name (`DataIdentifierNotFound`), which it
failed to load from the `rucio.client`. We had similar issue with
`RucioException` once, so now the new exception is handled similarly.

Rucio client module may raise not only `RucioException`, but also some
other exceptions: e.g. `IOError` (when files provided in the
configuration as user certificate/key can not be read).

What we need to do in case of a error in `init_rucio_client()` is to
make sure that this error can be distinguished from any other error
occured during the rucio client usage. In other words -- when we fail to
initialise the client, it is not a "Rucio error" (indicating that we
have some problems with Rucio), but a "dataflow error" (indicating that
we have some problems with the stage which is unable to do its job).

Calling `sys.exit()` is a bit severe: yes, we need to stop the stage
execution if we can't initialise the client; but it would also be
correct to say that we need to stop the dataflow. And, if
`DataflowException` is raised during the `process()` execution, it is
up to the common library to take care about the problem (output
necessary details and interrupt the stage -- or do whatever is the
default action when a stage says "I have a problem operating as a part
of the dataflow process").

Might be useful if we raise it instead of any other exception (and want
to specify our own exception message, but still would like to keep the
original exception information as well).

...to make the traceback shorter, and the topmost error message -- more
informative.

Conflicts:
	Utils/Dataflow/pyDKB/VERSION