fixed bug in logging high complexity query rejections

[irshadaj]

Description

A bug was introduced as part of #574 where we were attempting to log some fields that hadn't yet been populated from the buffer. This would result in nil pointer errors, panics, and/or empty logged fields. This manifested as the following error in the console when a cypher query exceeded the maximum complexity threshold:

The changes in this MR will populate all fields to be logged, before the log event is set up.

How Has This Been Tested?

Forced a query to exceed maximum complexity threshold by making the complexity analyzer (QueryComplexity function) return a high value

Ran a cypher query- this would trip the max complexity threshold and go into the high complexity log codepath. Error is shown at the bottom of the screen as expected.

Verified that the panic does not occur, and all expected fields are logged correctly

The other logging change sent out as part of the previous MR was related to neo4j timeouts. So I followed a similar strategy to force a neo4j timeout to occur, and verified that no nil pointers are thrown in that codepath.

Types of changes

• Chore (a change that does not modify the application functionality)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• Documentation updates are needed, and have been made accordingly.
• I have added and/or updated tests to cover my changes.
• All new and existing tests passed.
• My changes include a database migration.

[mistahj67]

I suspect there might be a way to have the single buffer but probably more work than it's worth.

Code LGTM and testing locally, no more panic, thanks for fixing!