Add endpoints to interact with User data

[AdamVig]

Missing:

• Set Property /setproperty username, password, propertyName, value
  Set a property in a user's doc. Search recursively for property, return descriptive error code if property or user does not exist.
• Create User /createuser username, password
  Create a user doc in the database, furnished with all necessary fields for initialization.

[AdamVig]

POST /setproperty should become PUT /[user]/[propertyname] in order to be RESTful. URL names should never include verbs.

POST /createuser should become POST /[user], with the other verbs implemented as well.

[AdamVig]

This addition requires significant architectural changes due to the nature of the endpoint being so different from other endpoints. Most endpoints simply have a getter and a processor and either handle GET or POST requests. This makes it easy to abstract away their functionality into the Endpoint helper class and instantiate them as a batch in index.js; both measures that help reduce redundancy in the code.

These two endpoints must interact with the User model.

• POST /user/[firstname.lastname] creates a user with the provided data in the users database
• PUT /user/[firstname.lastname]/[propertyname] updates an existing user with the provided data

This does not fit in with the existing model of retrieving and processing data in the endpoint. One option to work around it is to skip using the Endpoint helper class for these two endpoints. This is difficult to implement with the existing setup, however, because all routes in the /routes folder are dynamically instantiated when the app launches.

A possible fix could be to move the endpoint instantiation into the respective endpoint definition files in /routes. index.js would either dynamically import all of the routes or simply import a file /routes/routes.js that imports all of the enabled routes (this would remove the need to use an underscore to denote disabled files and would remove some of the unnecessary "magic" from the route loading strategy).

It might make sense to create a class for each endpoint that extends the main Endpoint class and overrides methods as necessary. This would likely be a better approach than passing configuration objects around.