Move core url data manager classes to content.

Move core url data manager classes to content.

BUG=169170
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=178663

[jam, 2013-01-24 00:10:22]

I've left forwarding headers so that this change doesn't get larger. in future
changes, I'll take care of them, renaming classes to get rid of "Chrome", and
moving code to content namespace.

[scottmg, 2013-01-24 00:22:07]

content/browser/webui/web_ui_data_source_unittest.cc unnecessary

lint complaining about some header sort orders

otherwise, lgtm

https://codereview.chromium.org/12049052/diff/1/content/browser/browser_main_...
File content/browser/browser_main_loop.cc (right):

https://codereview.chromium.org/12049052/diff/1/content/browser/browser_main_...
content/browser/browser_main_loop.cc:623:
ChromeURLDataManager::DeleteDataSources();
I think this happened after PostDestroyThreads previously. Will it be OK here?

[jam, 2013-01-24 06:42:52]

Albert: can you do a sanity check on my storage partition related changes? I'm
basically moving an object from Profile to BrowserContext (ChromeURLDataManager)
and from ProfileIOData to ResourceContext (ChromeURLDataManagerBackend).

The tricky part is patchset 4 to 5. This patch exposed a pre-existing race that
occurs if ResourceContext::SetUserData is called on the IO thread before
InitializeResourceContext is called on the UI thread. This didn't get hit before
because we didn't set user data on the IO thread at initialization. The problem
is that the map can be accessed on both threads at the same time. The fix I made
now (patchset 4 -> 5) is to ensure that InitializeResourceContext is called
before ResourceContext is used on the IO thread.

[jam, 2013-01-24 07:27:33]

btw I broke out that fix into https://codereview.chromium.org/12047075/ so that
I can try it and land it on its own.

[jam, 2013-01-24 19:44:57]

Albert: ptal. I've updated the patch to store URLDataManager on BrowserContext
instead of StoragePartition

[awong, 2013-01-24 19:55:29]

LGTM w/ nit

https://codereview.chromium.org/12049052/diff/3088/content/browser/resource_c...
File content/browser/resource_context_impl.cc (right):

https://codereview.chromium.org/12049052/diff/3088/content/browser/resource_c...
content/browser/resource_context_impl.cc:23: static const char*
kBlobStorageContextKeyName = "content_blob_storage_context";
The static is redundant here since were in the anonymous namespace.

Use const char* or preferably const char[]?

[awong, 2013-01-24 20:10:42]

https://codereview.chromium.org/12049052/diff/3088/content/browser/resource_c...
File content/browser/resource_context_impl.cc (right):

https://codereview.chromium.org/12049052/diff/3088/content/browser/resource_c...
content/browser/resource_context_impl.cc:23: static const char*
kBlobStorageContextKeyName = "content_blob_storage_context";
On 2013/01/24 19:55:29, awong wrote:
> The static is redundant here since were in the anonymous namespace.
> 
> Use const char* or preferably const char[]?

FYI, reading through c-style@, const char[] seems preferred.