Moved shell_util functions into new shell_registry_util module.

Moved shell_util functions into new shell_registry_util module.

These functions were previously static methods of RegistryEntry which
were taken out in r362608. This CL moves them into a separate file just
to avoid shell_util from being a giant mega-file.

BUG=419972

[Matt Giuca, 2016-01-12 03:20:40]

Description was changed from

==========
Moveed shell_util functions into new shell_registry_util module.

These functions were previously static methods of RegistryEntry which
were taken out in r362608. This CL moves them into a separate file just
to avoid shell_util from being a giant mega-file.

BUG=419972
==========

to

==========
Moved shell_util functions into new shell_registry_util module.

These functions were previously static methods of RegistryEntry which
were taken out in r362608. This CL moves them into a separate file just
to avoid shell_util from being a giant mega-file.

BUG=419972
==========

[Matt Giuca, 2016-01-12 03:54:41]

The CQ bit was checked by mgiuca@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-01-12 03:55:15]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1578833003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1578833003/40001

[Matt Giuca, 2016-01-12 04:37:15]

mgiuca@chromium.org changed reviewers:
+ gab@chromium.org

[commit-bot: I haz the power, 2016-01-12 04:43:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-12 04:43:01]

Dry run: This issue passed the CQ dry run.

[gab, 2016-01-12 20:16:14]

I would actually go a step further and also move all of the methods that do
registry operations.

i.e. the methods currently being moved would remain in the anonymous namespace
of shell_registry_util.cc and their users would be moved to the public interface
of shell_registry_util (from a cursory look it looks appropriate for all of
them)

In short, anything that says "register" or anything like it should move and I'd
like to keep as many of the currently anonymous methods anonymous as possible.

[gab, 2016-01-12 20:47:12]

FYI just saw this CL (https://codereview.chromium.org/1581473002) go by which
will probably result in merge conflicts.

[Matt Giuca, 2016-01-12 23:04:57]

OK I will take a look at which other methods deserve to be moved.

On 2016/01/12 20:47:12, gab wrote:
> FYI just saw this CL (https://codereview.chromium.org/1581473002) go by which
> will probably result in merge conflicts.

Thanks, I saw it in review so I was aware of it when writing this CL :)

[Matt Giuca, 2016-01-21 03:40:03]

Rebased.

Urgh, the merge conflicts for this sort of CL are very difficult and dangerous.
I can feel the same thing happening again as has happened a few times with these
shell_util refactors: the longer these CLs remain in flight, the harder it
becomes to update.

Can we land them in small steps instead of trying to refactor the world?

I had a small try at moving the remaining functions but they have lots and lots
of pieces and it got complicated. Also it isn't clear to me which ones. Let's
just land this and then look at that later, please? (They can go back to being
anonymous functions if they aren't used by any external functions.)

[gab, 2016-01-21 19:35:51]

On 2016/01/21 03:40:03, Matt Giuca wrote:
> Rebased.
> 
> Urgh, the merge conflicts for this sort of CL are very difficult and
dangerous.
> I can feel the same thing happening again as has happened a few times with
these
> shell_util refactors: the longer these CLs remain in flight, the harder it
> becomes to update.

Right, since they're just move though it's probably best to just redo the whole
move anywhere there's a conflict.

> 
> Can we land them in small steps instead of trying to refactor the world?
> 
> I had a small try at moving the remaining functions but they have lots and
lots
> of pieces and it got complicated. Also it isn't clear to me which ones. Let's
> just land this and then look at that later, please? (They can go back to being
> anonymous functions if they aren't used by any external functions.)

I don't like making a ton of code public only to all bring it back to anonymous
(I think it all should be anonymous and I think all of the existing callers
still in shell_util.cc in this CL are the ones that should move from the public
API of shell_util.h to the public API of shell_registry_util.h).

I can take this on from here if you want since I know what I have in mind and
it's probably easier that way for this final bit (plus I see most/all CLs that
go through here so merge conflicts should be easier for me to resolve/avoid)?