feat: Bigtable Authorized Views - Allow checkAndMutate and ReadModifyWriteRow calls on Authorized Views

[danieljbruce]

Summary:

This PR introduces the architecture required to service checkAndMutate and readModifyWriteRow requests for Authorized views.

Background:

this other PR has already been merged towards the effort of supporting data API calls for Authorized Views.

This current PR demonstrates the shape of the architecture that is required for Authorized View requests that correspond to the checkAndMutate and readModifyWriteRow calls currently serviced by calling the Row class methods. There may be clerical mistakes, but those will be flushed out by writing unit tests and integration tests.

Changes:

Row Data Utils:

• Code from increment, filter and createRules in the Row class is moved into new methods in row-data-utils. To support authorized view calls this has to be done. You see, increment, filter and createRules on the Row class make use of a private data property in that Row class. For this reason, to support increment, filter and createRules for authorized views we cannot simply create increment, filter and createRules methods on the TabularApiSurface class because then data would have to be passed into them and we do not want data to be part of the method signature. Instead, we move increment, filter and createRules functionality from Row to methods in a shared row-data-utils class. These methods in the row-data-utils class will now make requests for both tables and authorized views.

Authorized View:

• increment, filter and createRules methods are added to the new AuthorizedView class for making checkAndMutate and readModifyWriteRow calls for an authorized view. These methods should not be exposed on TabularApiSurface because then they will be exposed on Table, but this functionality is already available for tables on the increment, filter and createRules methods on Row.
• The createRules, filter and increment methods on the AuthorizedView class will have the same signature as the methods with the same name on the Row class except they must also be provided with a row id that the request will be made for.
• The AuthorizedView class will store row data for authorized views just like the Row class has a data property that stores data for that row. This rowData variable in AuthorizedView stores data for each row it makes a request on behalf of.

Row:

• Existing method bodies are moved to RowDataUtils and replaced with one line of code that delegates the call.

Table:

• A view method is added which will be used for creating authorized views
• A constructor is added matching the constructor that was in Table before. This is needed now that the TabularApiSurface constructor is protected.

TabularApiSurface:

• The constructor is now protected since the class isn't meant to be instantiated directly
• A viewName member is added and will be undefined for tables, but provided for authorized views

test/Row.ts

• Since the code has been moved then different files need to be mocked in proxyquire and sinon so these mocks are adjusted.

Next Steps:

1. Write some tests that use the new increment, createRules and filter methods now available on AuthorizedView. Make sure that these methods pass the proper parameters along and that they target an authorized view.
2. Write a PR for supporting authorized views calls for all methods of the TabularApiSurface class.

[bhshkh]

Well organized code. Thanks for adding the detailed description regarding the changes in the PR!