[base/files] Respect MAC_CHROMIUM_TMPDIR instead of TMPDIR on macOS.

chrome/browser/extensions/api/developer_private/developer_private_api_unittest.cc

Index: chrome/browser/extensions/api/developer_private/developer_private_api_unittest.cc
diff --git a/chrome/browser/extensions/api/developer_private/developer_private_api_unittest.cc b/chrome/browser/extensions/api/developer_private/developer_private_api_unittest.cc
index a2718f67e5ce40efcc9f35bd04faa219dbe37078..666988433f52ba2e69e3f66c41399d397ab416b5 100644
--- a/chrome/browser/extensions/api/developer_private/developer_private_api_unittest.cc
+++ b/chrome/browser/extensions/api/developer_private/developer_private_api_unittest.cc
@@ -604,7 +604,7 @@ TEST_F(DeveloperPrivateApiUnitTest, LoadUnpackedRetryId) {
            "version": 1,
            "manifest_version": 2
          })");
-  base::FilePath path = dir.UnpackedPath();
+  base::FilePath path = base::MakeAbsoluteFilePath(dir.UnpackedPath());

[Devlin, 2017/03/29 15:15:43]

Hmm... this doesn't seem like quite the right place to do this.  A few different
options:
- At minimum, we should probably hoist this up to TestExtensionDir::UnpackedPath
(and probably apply a similar change to the value returned by Pack()).  I
*think* that will be a fairly easy change that doesn't break anything.
- That said, TestExtensionDir basically just relies on ScopedTempDir - would it
make sense to have ScopedTempDir return the absolute path to prevent this kind
of misuse?  I don't know if anything is currently relying on a non-absolute path
being returned by ScopedTempDir...
- How crazy would it be for FilePath::operator== to return true if the absolute
paths are the same?

I'd probably be fine with any of these options, but if we go for the less
general-case one (modifying TestExtensionDir), it'd be good to know the
reasoning for why the others would be incorrect.

   api::EntryPicker::SkipPickerAndAlwaysSelectPathForTest(&path);
 
   DeveloperPrivateAPI::UnpackedRetryId retry_guid;