Currently we react to any change to the system.views collection (other than dropping it) by explicitly reloading the view catalog for the database. This was necessary back when we allowed direct user writes to the system, so invalid view definitions could be persisted. Since SERVER-43633 prohibited direct user writes to the system.views collection, we could now handle operations with a bit more finesse.

In particular, we could add different handlers for insert, update, and delete, to make more granular updates to the CollectionCatalog. We may want to refactor a bit to share functionality with the createView, modifyView, and dropView functions, without generating additional oplog entries; however, it's also possible we want a completely separate code path for handling the oplog entries as the logic we perform will likely not use the same type of error handling.