ANDROID: sched/tune: fix boost_group spin_lock re-initialization

In:

  c5616f2f   ANDROID: sched/tune: Initialize raw_spin_lock
                in boosted_groups

a spin_lock is initialized on each CPU every time a boost_group is
activated (i.e. a cgroup created).

However, those spin_lock are already initialized at boot time by
schedtune_init_cgroups() which also set schedtune_initialized to true
thus enabling the tasks accounting done by schedtune_{en,de}queue_task().
This means that an already initialize and used spin_lock is wrongly
re-initialized thus potentially leading to a:
   BUG: spinlock already unlocked on CPU
in the (unlikely in AOSP) case we have a race between schedtune cgroups
creation and tasks enqueue/dequeue.

This probably happened because the fix provided by c5616f2f was just
the wrong cure for a different issues: the missing one-time
initialization of the per-CPU spinlocks in schedtune_init_cgroups().
All these fixes happened on v4.4 and have been forward ported to the
current v4.9 base.

Let's better fix this by:
- removing the not necessary spinlock re-initialization in:
  schedtune_boostgroup_init()
- add a new "valid" flag to better flag which boost_groups are currently
  used to track a valid cgroup.

This patch adds also a better documentation of the used data structures
and the locking strategy in use to synchronize fast and slow paths.

Change-Id: I3c2a256693b12b317373bbc032ed46e620f79ee8
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Reported-by: Stanley Shih <stanley.shih@mstarsemi.com>

[
The first of the two fixes listed above has been already
merged by:

   commit f6bec4e8 ("Revert "ANDROID: sched/tune:
                         Initialize raw_spin_lock in boosted_groups")

which, in conjunction with:

   commit 751e5093 ("ANDROID: sched: tune:
                         Fix lacking spinlock initialization")

provides the correct initialization of the boostgroups spinlocks.

Let's keep the changelog as it is to better keep track of the original
intended fix as well as to better document the required locking strategy.
]
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>