Because for the creation UI we're using optimistic update logic where we call readFragment method. When a fragment has another nested fragment we have to specify the main fragment name (the root one) for the Apollo cache. Otherwise Apollo throughs an error about this problem.
Also in this PR, I changed main insight interfaces and mark filters as optional because in the creation UI we don't deal with filters and we don't have it. But prior to this PR insight interfaces always required filters object. Which led to the complex insight creation flow. At the moment our GQL creation mutation doesn't support filters input and in case we need to create insight with pre-defined filters (like creation insight through the drill-down panel) we have to make two network requests (1. create insight mutation, 2. update filters in the newly created insight)
Well because interfaces always required these filters we used complex flow for the just insight creation. In this PR since filters isn't a required field anymore we could run just create insight mutation and don't care about filters flow anymore (we still care about this for the drill-down creation flow)
