Qblox backend

Note: as of 23/04/2021 this backend requires strictly v0.3.2 of the qblox-instruments package. If you are using this code, please update qblox-instruments to this version.

Explanation of changes

Qblox backend refactor. The main goal is to improve maintainability of the code as the old backend outgrew its structure. Summary of important changes:

• All the large functions have been broken up in much smaller functions, to improve maintainability.
• _prepare_pulse function removed and replaced by a general approach rather than waveform specific.
• Explicit data structures introduced.
• Single letter variables removed in favour of descriptive names.
• Compilation flow now mirrors the modular implementation of the ControlStack (!70 (merged))
• Improved exception messages, which should allow easier debugging in the lab. The aim is to explicitly mention which pulse/acquisition/setting triggers the exception, in a way that can be understood on the Schedule level.
• Proper documentation for every single function in the backend.
• Removal of duplication and redundant code.
• Removal of code that makes changes to the schedule that is being compiled, in favour of passing information explicitly.
• Consistent use of type hints
• Renaming pulsar_backend -> qblox_backend

Effectively this constitutes a rewrite of most of the backend and needs to be tested thoroughly. Ideally now the code is structured in a way that can survive past v1.0.

Also closes #101 (closed), #93, #86 (closed), #74, #73 (closed), #59 (closed) and #89 (closed)

Features still to be implemented before merge

• Fully support Schedule.repetitions. Currently all the infrastructure for this is in place but property is not yet used.
• Edit this MR and !70 (merged) such that they work together properly It appears nobody is currently using the code from MR !70 (merged) so we can safely postpone this.
• Move general utility functions to separate files
• Remove utility functions that duplicate those implemented in MR !49 (merged)
• Fix TODOs and FIXMEs that can be solved currently
• Write documentation
• Test on hardware
• Old backend and references to it removed

---

Merge checklist

See also merge request guidelines

• Merge request has been reviewed and approved by a project maintainer.
• Merge request contains a clear description of the proposed changes and the issue it addresses.
• Merge request made onto appropriate branch (develop for most MRs).
• New code is fully tested.
• New code is documented and docstrings use numpydoc format.
• CI pipelines pass
  • black code-formatting passes (gitlab-ci),
  • test suite passes (gitlab-ci),
  • no degradation in code-coverage (codacy),
  • no (serious) new pylint code quality issues introduced (codacy),
  • documentation builds succesfully (readthedocs).