Update linux disk_encryption to recursively query parent crypt status

[Micah-Kolide]

This change will rely on #8037

Functionally this should minimize getting encryption status from parent devices, but without the constraint being added in block_devices this will not perform well.

Below is the process of acquiring crypt status and overall what is different.

1. Query block devices all or by name constraint
2. Generate encryption row for each queried block device
   • If current block device has encryption
     • Set the encryption row with those values
   • If current block device does not have valid encryption
     • If we have a parent block device defined
       • If we need to create the parent's encryption status
         • If we need to query the parent block device
           • Query the parent block device
         • Generate parent encryption status
       • If we have already generated an encryption status for the parent
         • Use already generated parent device's encryption status
     • If we do not have a parent i.e is a root device
       • Set unencrypted status for this device
3. Add encryption row results to output if that device was a part of the initial query

This avoids sorting parents altogether, which I figured made sense here.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Micah-Kolide (baab9f3, 7008ef1, 38fc6dc, 65ab341, 9a87438)

[sharvilshah]

I have not built/tested this branch locally, but the code/flow seems fine.

[directionless]

I walked through the code. I think it works, but could use a coupe more comments. And maybe we can swap in an early return and ditch the else.

[directionless]

I think @Micah-Kolide is manually testing, but I think this is correct

Micah says he's still tinkering

[directionless]

@Micah-Kolide and I spent a long time tinkering with this. And ultimately, while there are several issues around efficiency, this seems worth merging as is. But, notes for next time...

disk_encryption needs block_devices. And unfortunately block_devices does not support query context. (see #8152) By extension, disk_encryption does not support query context. Thus, it does not declare any indexing, and in theory it should be correct. However...

Somewhere in osquery/sqlite there appear to be two issues.

1. sometimes when called as select * from foo where x in (a, b, c) foo is called 3 times. This feels suspect.
2. when used in a join, as SELECT * FROM mounts m LEFT JOIN disk_encryption de ON m.device_alias = de.name; it it called once per mount. This makes for some horrific performance.

In both cases, playing with index, additional and cachable do not fundamentally change the outcome.

These feel like bugs in osquery, and I think I've seen them in the past. I do not think they should block this merge, as this is an improvement over the status quo.

[directionless]

Ha. The issues I describe are exactly covered by #5379. I knew I'd seen them before