chore: remove pendingmessage functionality

[shreddedbacon]

Checklist

• Affected Issues have been mentioned in the Closing issues section
• Documentation has been written/updated
• PR title is ready for changelog and subsystem label(s) applied

The pending messages functionality of the remote-controller never really worked well, and in clusters that typically do exhibit signs of queue instability the pending messages functionality didn't actually work in a lot of cases.

Rather than try and support a feature that adds additional complexity for not much gain, this PR is to remove it. It retains a command line flag but in a noop capacity, which should be removed in a future version.

The removal of this feature will mean that if there is a problem communicating back to rabbitmq during a build, that there is the possibility that the logs for the build may be lost, or the status of the build may be unknown. PR #224 also helped reduce the need for the pending messages check, along with older PRs that enhanced build cancellation functionality to attempt to retrieve the status of builds if a cancellation is received, #211 and associated PRS

Adjusting the flags num-builds-to-keep and num-build-pods-to-keep beyond the default of 1 can also help to retain logs longer in clusters that may exhibit communication issues with rabbitmq more frequently, but generally should not be required.

[bomoko]

Looks good, makes sense.

Nice simplification - especially if the existing mechanism is flaky.

[shreddedbacon]

Just looking back at this, there are considerable changes to the CRD here that "may (unlikely)" cause problems if we removed them from the CRD. I think I will leave this for now, but create a new PR that refactors the CRD to create a newer v1beta2 api version where this information doesn't exist, and we can start work on being able to deprecate APIs, as this would also make it easier in the future to do more drastic CRD changes if required.