Move mongo schema format related logic into mongo adapter

[drew-gross]

Soon, Parse Server will have no idea what the mongo format looks like. This PR is a work in progress, there are some tests that fail locally that seems unrelated to my changes, I want to see if they fail in Travis. Also it needs some cleanup.

[flovilmart]

👍

[codecov-io]

Current coverage is 92.78%

Merging #1385 into master will decrease coverage by -0.07% as of 68ab2b3

@@            master   #1385   diff @@
======================================
  Files           85      86     +1
  Stmts         5442    5435     -7
  Branches      1003    1002     -1
  Methods          0       0       
======================================
- Hit           5053    5043    -10
- Partial          9      10     +1
- Missed         380     382     +2

Review entire Coverage Diff as of 68ab2b3

Powered by Codecov. Updated on successful CI builds.

[drew-gross]

Changed my mind about this being WIP, since it passed tests and the horrible parts mostly got removed already before I submitted.

[flovilmart]

do we really need to add lodash for 1 function?

Object.keys(parseFormatSchema).map( key => {
  let parseField = parseFormatSchema[key];
  return schemaAPITypeToMongoFieldType(parseField).result  
})

[flovilmart]

1 small nit, not really into adding an extra lib if it's just for one function.

[drew-gross]

We already indirectly depend on lodash anyway, and there are also a lot of other things it will be useful for like set intersection, set union, deep flatten, deep clone, etc. If you guys don't want lodash we can remove it but I think it's a pretty sweet utility library and will be able to simplify a lot of stuff for us.

Also I think you misunderstand mapValues, it's more like

_.mapValues(val => val.toString(), {a:2, b:5}) === {a: '2', b: '5'}

So it can replace nearly all of our uses of reduce.

[flovilmart]

Alright then, yes this is very useful, I usually use it.

[nlutsenko]

This doesn't belong here. Mongo should have 0 clue on what is a CLP in my opinion, since it's purely top level abstraction in Parse world.
Also, if we are going to have this on other database adapter - do we probably would need to go copy/paste at this point.

[nlutsenko]

A single comment about default CLPs, since I don't think that's the proper place for them.
Maybe abstract them into a separate utility function for schema or type conversions?

[drew-gross]

Yeah I think probably the best way to store schema metadata like CLPs + pointer permissions + future features is probably to just give the adapter an opaque blob and expect it to return the same blob back. It's worth having a larger discussion about, though, I think. I'm going to merge this anyway, and refactor that later.