Sometimes we have to interact with the same storage in different
scripts. When it happens we got to implement same functionality multiple
times: read configuration, check that Python module is available, create
client, ...

This submodule is a place to implement this once and then reuse whenever
it is needed.

Initial module structire:

```
pyDKB
  |---> storages
          |---> exceptions
          |       |---> StorageException
          |       |---> NotFound
          |
          |---> client
                  |---> Client
```

Suggested way of the `pyDKB.storages` usage is:
```
from pyDKB import storages

def processA(...):
    rucio_client = storages.getClient('rucio', 'atlas')
    rucio_client.get_metadata(...)
    ...

def processB(...):
    rucio_client = storages.getClient('rucio', 'atlas')
    rucio_client.get_metadata(...)
    ...
```

The client used in `processA` and `processB` (and at every call of a
function) will be the same instance, initialized at first call. In other
words, client classes for individual storages are "singleton" classes
(as long as used via `getClient()` methods, not directly).

"Scope" abstraction is introduced to keep project-specific fucntionality
localised in a single submodule, preventing it from infiltration into
other, more general modules. Each "scope" is nothing but a submodule of
`pyDKB.storages`. It must contain pre-configured clients for the storages,
used in a given project and support general access method to these
clients (`getClient()` function).

It allows to get clients simply by name, not specifying the scope every
now and again:
```
from pyDKB import storages
storages.setScope('atlas')

def processA(...):
    s = storages.getClient('rucio')
    s.get_metadata(...)
```

…class.

The idea of the interface to provide common set of methods to interact
with different storages, not to (re-)implement all possible methods of
interaction with storages. But different storages may have specific
methods, and calling them as `my_client.c.client_method_A()` will look a
bit wierd: `my_client.client_method_A()` looks more natural.

To avoid re-implementation of all useful methods in this way:
```
  def client_methodA(self, *args, **kwargs):
    self.c.client_method_A(*args, **kwargs)
```

multiple inheritance will be used:
```
  class MyClient(pyDKB.storages.client.Client, ParentClientClass):
    ...
```

In case of `ParentClientClass` having same methods as Client, by default
`Client` (interface) method will be used, raising `NotImplementedError`.
If `ParentClientClass` method should be used, it is to be specified
explicitly.

"id" is a reserved word in Python, so it should not be used as variable
or parameter name.

Original Rucio `Client` does not have `get()` method.

Currently it is nothing but a wrapper around standard
`elasticsearch.Elasticsearch` class, except that its `get()` method is
overridden with `Client.get()` that raises `NotImplementedError`.

It allows to pass configuration to the client as hash.
`__init__()` accepts parameters in the form consistent with the
`elasticsearch.Elasticsearch()` parameters, so it is not possible to
pass default index name when the object is created.

Co-Authored-By: Evildoor <[email protected]>

There's only two possibilities: an exception was or was not thrown.
Whatever exception it is, it indicates that we failed to import
something we wanted to import => so we must return a value that
indicates "import has failed" -- `False`.

…()`.

Who knows what value has this or that attribute one wants to import,
right? And `False` looks like a pretty possible one... while string "NOT
IMPORTED VALUE" should be less expected and I believe it won't conflict
with real attributes values (except itself, but hopefully no one will
use this function to import something added as service variable for this
function itself).