MonitorCookies are marshalled as a json object, not an array. Fix it so
that benchmark test works

Signed-off-by: Adrian Moreno <[email protected]>

Signed-off-by: Adrian Moreno <[email protected]>

Clearly DBModel does not hold the full database model. Instead, only
the combination of model.DBModel, mapper.Mapper and ovsdb.Schema is a
useful database model as is used internally by libovsdb.

The fact that server.go had to defined a struct called DatabaseModel
with model.DBModel and ovsdb.Schema and dymanically create Mapper
objects from them is a proof of this.

In order to prepare for a DBModel refactoring, rename it to
ClientDBModel as it's the client's view of the DatabaseModel.

This patch does not contain functional changes

Signed-off-by: Adrian Moreno <[email protected]>

Replace the one that server.go had to define. For now, it's just a
drop-in replacement of the previous type.

Signed-off-by: Adrian Moreno <[email protected]>

It is common to first create a DatabaseModel only based on the
ClientDBModel, and then add / remove the schema to it when, e.g:
when the client (re) connects.

Validation is performed when the schema is added.

Since the schema and mapper can be dynamically added and purged, protect
them with a RWMutex

Signed-off-by: Adrian Moreno <[email protected]>

For the cache, it's simply replacing three fields with one
For the client, use the 2-step DatabaseModel initialization

Signed-off-by: Adrian Moreno <[email protected]>

Now that client, cache and server uses the DatabaseModel as central
point of model creation and introspection, we can hide the
dbModelClient and move its public functions to the DatabaseModel

Signed-off-by: Adrian Moreno <[email protected]>

All around the codebase we're creating mapper.Info structures and then
calling Mapper functions that create Info structures again.

Given that mapper.Info already defines all the metadata that Mapper
needs to do the native-to-ovs transations, it makes sense to use Info
structures as input to all functions.

That simplifies the code inside the mapper module. Also, I'd expect some
performance improvement since we were creating multiple Info structs
unnecessarily in the host path.

It's true that, for now, it makes it sligthly more cumbersone to call
mapper functions, since the Info struct has to be created first and it
now requires an additional argument (the table name). However, this
can be improved later on by having the database model build the
Info structs for us.

Signed-off-by: Adrian Moreno <[email protected]>

The core mapper API uses mapper.Info sctructs which can be created just
by inspecting a TableSchema.

However, having the DatabaseModel now centralizing accesses to the
mapper API and containing both the Model types and the Schema, we can
pre-create the mapper.Info.Metadata sctructs and cache them so we create
Info sctructs more efficiently

Signed-off-by: Adrian Moreno <[email protected]>