Remote mtime updates may be lost if inode has already been observed

[jacobsa]

As documented in this commit, we don't observe mtime updates made remotely when an inode has already been assigned locally. This is a bit weird, and maybe annoying if you're using gcsfuse as an rsync destination on one system and source on another.

This is because from our point of view GCS objects are only "mostly" immutable—a given generation's data can't change, but it's metadata (which includes gcsfuse_mtime), can. But GCS offers metadata generation numbers for exactly this purpose.

So:

• Update semantics.md to specify that identity is on both generation and metadata generation. So even updates to metadata may cause a file to appear unlinked.
• Add integration tests for the identity logic. Look to existing 'clobbered' tests for inspiration.
• Add an integration test for setting mtime metadata for a file we've already observed.
• Update FileInode and friends so that their SourceGeneration methods return both a generation and a metadata generation.
• Pay attention to both in fileSystem lookup code.
• Remove the note from semantics.md.

After this we'll observe remote mtime updates after the stat cache ttl expires.

[jacobsa]

Also:

• Wherever a generation number is used to address an object or as a precondition, we want to also use metadata generation.