Add parsing metadata from crud response

[ArtDu]

Now we can obtain metadata from the response and don't use metadata from ddl.

I didn't forget about:

• Tests
• Changelog
• Documentation
• Clean up the code for review. See checklist

Closes #272

[ArtDu]

The main problem is that now we have two converters used to parse incoming tuples:
The first level parses the top level - container - List of tuples or crud response.
The second level parses one tuple at a time.

The second level always needs to know the metadata, because it creates a TarantoolTuple and passes it there. Right now it only gets the metadata from the constructor.
The conclusion is the level that parses a particular tuple must know the metadata from the level above, if it is crudResponse.

So I see 3 options:

1. Create a new fromValue method, into which we can pass custom metadata, as I did in PR - minus that we add a method to the API, although the method is not giant terrible)
2. Combine the first and second levels - consider combining two converters into one - minus, that everything is in one place parsing the container and the tuples themselves
3. Create a converter for each request of the second level - minus the memory will be painfull grown

[akudiyar]

I think the new converter variant (3) is the best because it doesn't allow to leak the implementation details through interfaces and leaves in place the ability to have different result mappers (e.g. for libs other than Tarantool/crud or non-tuple results).

The converter instantiation is a parallel problem and should be dealt with as a whole, not in this particular place.

[akudiyar]

It's a better idea overall then changing the ValueConverter interface, however the changes look very rough. I'd rather not copy-paste the whole converters code in that way. Also It may be worth thinking about passing a tuple converter factory to the result converter instead of a tuple converter, that will help eliminating the fromValue method and unnecessary casts.

[ArtDu]

@akudiyar @Elishtar Can you look it again? We don't have a lot of codes here after #300 was merged

[akudiyar]

What's the purpose of this class? Currently it looks like doing nothing.

[ArtDu]

I changed classes. You should check

[akudiyar]

This class needs some unit tests and a Javadoc.

[ArtDu]

They're already tested in integrations tests. I don't think it's nessasary to think about syntaticly creation of ddl, _vspace, crud methods answers

[akudiyar]

This class needs some unit tests and a javadoc.

[ArtDu]

Fixed

[akudiyar]

Shouldn't it take MapValue explicitly?

[ArtDu]

If we want to have one interface for metadata parsing we need to use Value. Metadata can be stored in different structures

[ArtDu]

I changed it

[akudiyar]

This class needs unit tests and a Javadoc.

[ArtDu]

Fixed

[ArtDu]

We can split PR to "Parse metadata from crud response" 3252ba6 and "Refactor metadata parsing". But I prefer to merge "Parse metadata from crud response" 3252ba6 for first

[akudiyar]

Interestingly, that looks pretty OK without all the other changes, one question is left though

[akudiyar]

Do we really need to make it public? It's an internal implementation class.

[ArtDu]

There are two options here:

• package private - We store converters(parsers in future) in *.core.metadata package
• public - we open this class and store classes where they should be semantically

[ArtDu]

First option has been picked up

[akudiyar]

LGTM