[PSA] base::raw_ptr<> and pointer arithmetic

[Tom Sepez]

If you do not use base::raw_ptr<> in your code, you can stop reading now (except to say that you should be using base::raw_ptr<> in your code).

Summary: If you see a build error of the form "cannot increment raw_ptr unless AllowPtrArithmetic trait is present" or "cannot index raw_ptr unless AllowPtrArithmetic trait is present", it's my fault. Read on for how to fix this.

Details: One of the main issues impacting chrome security is spatial safety -- in other words, errors caused by the misuse of C-style pointers that refer not to a single object, but to an array of objects. This carries over to the world of base::raw_ptr<> in that a base::raw_ptr<> can currently refer to a single object or to an array of objects. We'd like to disambiguate the two cases so that we can know the set of places where spatial errors can occur. base::raw_ptr<> already supports the notion of annotations (as is currently used for, say, DanglingUntriaged). We're extending the same mechanism to annotate raw_ptrs<> upon which pointer arithmetic can be performed as this is a sure sign that the pointer points to an array of objects.

To annotate such a pointer, instead of writing `raw_ptr<T> member_;`, use `raw_ptr<T, AllowPtrArithmetic> member_;'.  This is a compile-time check and does not add any overhead. Failure to do so will result in one of the above errors when attempting to instantiate the raw_ptr's increment, decrement, and index operators during compilation. I am currently landing CLs to fix all known occurrences (of which there are surprisingly few).

The mechanism to enforce this requirement is already in place, but is not yet enabled on any of the builders.  Gun jumpers who wish to jump the gun and see this in their local builds can set the GN argument `enable_pointer_arithmetic_trait_check=true`

Additional details may be found in the "Pointer Annotations" section of the base/memory/raw_ptr.md file.

Please ping me with any issues.  Thanks Heaps!