Python has a specific function to join paths for a reason. Let's see some examples why:
```python
>>> import os
>>> p1 = '/'
>>> p2 = 'foo'
>>> os.path.join(p1, p2)
'/foo'
>>> os.sep.join([p1, p2])
'//foo'
>>> p2 = '/foo'
>>> os.sep.join([p1, p2])
'///foo'
>>> os.path.normpath(os.sep.join([p1, p2]))
'/foo'
>>> p2 = 'foo'
>>> os.path.normpath(os.sep.join([p1, p2]))
'//foo'
>>> p2 = '/foo'
>>> os.path.join(p1, p2)
'/foo'
>>>
```
Also, python docs also state the knowing the OS separator is not always enough to parse/join paths, see http://docs.python.org/library/os#os.sep
There are some posts on the internet which state that `os.sep.join` is faster that `os.path.join`, and, most likely it is, but is it THAT faster? Does that really make a difference in salt's context, specially since it's error prone as shown above?
When using `--no-clean` while running tests, some files/dirs still need to be removed, if not, test will fail. This commit tries to addresses those issues.
Now, when running the salt loader, we get dotted names for the loaded modules, states, etc.
Instead of, for example `foo_module`, `bar_state`, we now get `salt.loaded.module.foo` and `salt.loaded.state.bar`, etc.
This will greatly help using the granular log filtering.
Reused the output options and logging setup mix-ins.
Fixed a bug introduced in previous commit on `salt.utils.parsers.SaltCPOptionParser._mixin_after_parsed()`, function does not accept any arguments.
For this, the timeout mix-in and both the target and output parser group mix-ins were re-used. Way less code and logic to keep track of.
Added a simple test for this binary too.
* Created 2 mix-ins as option groups, the output options and the target options. This will allow adding some explanatory text besides separating these options from the parser's main options.
* All options on the parser, including the grouped options are now merged to the loaded configuration which will latter get passed on.
* Also created the timeout mix-in which will be used in other binaries.
Introduces two new module functions: network.subnets and
network.in_subnet. The former returns a list of subnets to which the
minion belongs, and the latter returns True/False depending on whether
or not the minion belongs to a given subnet. Note that the argument to
netork.in_subnet need not be a subnet from the list provided by
network.subnets.
