AsComponent: Centralize GOnce guard to fix an assertion failure

[smcv]

• trivial: Make as_component_create_token_cache static

  It's no longer called from outside AsComponent, so it doesn't need to be
  extern any more.

• AsComponent: Centralize GOnce guard to fix an assertion failure

  The token cache only needs to be created once per AsComponent.
  Previously, each of the two callers of as_component_create_token_cache()
  guarded it with an atomic (GOnce) access to priv->token_cache_valid,
  but the implementation had a redundant non-atomic guard. This resulted
  in a GLib assertion failure on leaving the function, because the atomic
  boolean flag indicating whether initialization has completed is not
  meant to be set non-null until g_once_init_leave().

  In particular, this resolves test failures in Flatpak 1.13.x
  (which has been ported from libappstream-glib to libappstream) when it
  runs flatpak search from its test suite.

  Resolves: flatpak search assertion failure since port to libappstream: g_atomic_pointer_get (value_location) == 0 #384

[smcv]

I'm not 100% sure that this use of g_once_init_enter/g_once_init_leave is correct, even with this change, because it's documented to need a pointer to a static initialization guard, and libappstream is using it with a pointer into a dynamically-allocated data structure.

However, this change seems like a step in the right direction either way, and it resolves the crash I observed.

[ximion]

Indeed, and I do think this is exactly the right fix right now - in case the data structure being dynamically allocated causes a problem (I'll need to have a look at what GLib is actually doing there), we could always use a mutex, or maybe better GLib's atomic operations helpers.
Thank you for the patch, sorry for the review delay (vacation had to happen ;-) )

[xerexcoded]

AppStream version: 0.15.2 , still does not have this merged , hopefully the next version will resolve the error .