Adding ASOTracker

Currently, WMAgent has no idea of what ASO is doing. This basically
means throwing away/redoing a lot of code WMAgent already has written:

* DBS Publication (this was super hard to get right)
* Error handling/retry (this interacts deeply with the agent)
* Monitoring

Additionally, it doesn't make much sense conceptually to seperate out the
status of ASO from the rest of the agent. Currently the agent looks at
s FJR, and sees that the file is at site X, and everything's done. But
really, the file is (possibly) being moved to site Y, (possibly) has a new
LFN and (possibly) failed to even make it to the new place.

This patch make a new component (AsyncStageoutTracker) and adds a few new
states to the JSM to let it keep track of files that are moving. The
ASOTracker monitors ASO's user_monitoring database to figure out when files
have completed moving and them moves it to asocomplete/asofailed states
which can then be picked up by the JobAcountant where it's handled like
a normal job.

Since everything's contained in the agent, all the normal stuff works
right. You can publish to DBS, look at WMStats and have the error
algorithms fire the same way. You don't have to worry about combining
WMStats with the ASO database, and you don't have to worry about
maintaining a lot of old code.

One of the motivations for having the current architechture was
that ASO should be "decoupled" from WMAgent. I'd argue that this is
less coupled. Previously, it is a hack on top of a hack to, for
instance, figure out what job should be retried. A client would need to
have intimate knowledge of both ASO and WMAgent. This just requires
having the ASO user_monitoring database available. I'd argue that if
cmsweb's couch instance goes down, all bets are off anyway (since you
could no longer update WMStats, GlobalWorkqueue, etc..), and it's a
worthwhile tradeoff to remove a ton of glue code to keep two
seperate subsystems in sync

Conflicts:

	src/python/WMCore/WMSpec/StdSpecs/Analysis.py
	src/python/WMCore/WMSpec/StdSpecs/DataProcessing.py
	src/python/WMCore/WMSpec/StdSpecs/MonteCarlo.py
	src/python/WMCore/WMSpec/StdSpecs/StdBase.py
Adding support to write files into sub-user space

Current (CRAB2) LFNs support LFNs that look like

/store/user/lpctlbsm/meloam/blah/blah

Where lpctlbsm is the group name. Not only is it really conveniant
to be able to keep an idea of whose files are which in the group storage
(i.e. du -ckhs or dcdu -ckhs), but end-users are going to expect their
files to end up on the same place, regardless of what tool was used to
produce them
Merge remote-tracking branch 'upstream/master'

Pull from WMCore 0.9.27
Merge remote-tracking branch 'origin/asofix-clean'

Pulling in the asofix-clean branch to master

Conflicts:
	src/python/WMComponent/ErrorHandler/ErrorHandler.py
	src/python/WMCore/JobStateMachine/Transitions.py
	src/python/WMCore/WMSpec/StdSpecs/DataProcessing.py
	src/python/WMCore/WMSpec/StdSpecs/MonteCarlo.py
	src/python/WMCore/WMSpec/StdSpecs/StdBase.py
	test/python/WMComponent_t/JobTracker_t/JobTracker_t.py
	test/python/WMCore_t/JobStateMachine_t/ChangeState_t.py
Merge remote-tracking branch 'origin/feature/subgroup-storage'

Add LFN rules to allow storage in subgroup space i.e.:

/store/user/lpctlbsm/meloam/foo/bar/baz
Bugfix preservelfn

Adds the right bits to the stageout step to propagate preserve_lfn
to ASO and central monitoring
Merge pull request #18 from PerilousApricot/bugfix/preservelfn

Bugfix preservelfn
Merge branch 'master' of github.com:PerilousApricot/WMCore into se2-install

Conflicts:
	src/python/WMComponent/AsyncStageoutTracker/AsyncStageoutTrackerPoller.py
	src/python/WMComponent/JobAccountant/AccountantWorker.py
	src/python/WMCore/JobStateMachine/Transitions.py
	src/python/WMCore/WMSpec/StdSpecs/StdBase.py