Consider refreshing authorization metadata upon altering tables

The KUDU-428 design doc doesn't touch on the impact of altering table schemas. Tokens and privileges don’t currently get refreshed upon altering a table, which could eventually lead to unintuitive behavior. Take the following series of events:

1. Get a token that authorizes the client for some columns of a table
2. Client adds a column and waits for it to complete
   1. It doesn’t get a new authz token because the token hasn’t expired
3. It tries to scan from the column that it just created
4. This fails because the token doesn’t have the privilege for that column
   1. As implemented, this is a fatal authorization error and the scan will not be retried – the expectation being that privileges are relatively static, and that if you don’t have the privileges, trying to refresh your privilege will not help
5. The client must OpenTable to get a newer token

This will happen even if the user has permissions on that column. This is a poor user experience. Some solutions?

• Invalidate master-side privilege cache every time we complete an alter table.
• Similarly, send a new token alongside responses to a successful IsAlterTableDone.

Now what if the user didn’t have permissions on that column because they didn’t add the privileges in Sentry yet? The above solution would not work (i.e. a new token wouldn't help because the privileges in Sentry wouldn't reflect the new column). Some solutions?

• The user is forced to wait until the privileges are added in Sentry, and then for the privileges in the cache to expire, and then OpenTable().
• Alternatively, user must have all scan privileges on the table.