Fix #11, Implement setting X-Audit-Log-Reason header

[Chris-Johnston]

Fix #11

This adds an optional reason parameter to all relevant methods (those with corresponding event Audit Log event types) to the rest API tasks. When this parameter is not null, it's value will be included as part of this header.

I had questions about a few implementation details:

• Should this header be an option for all rest endpoints, not just these?
• Given the current tests, I'm not sure of a great way to test that this header is included. I was able to debug that the controller did receive this header when it was not null.

[AntiTcb]

I think moving the header declaration to be a property akin to the authorization header would be more appropriate than passing it in as a method parameter. This would make it accessible immediately to any new endpoints that arise that can utilize it for audit logging.

The client would need to null out this property after every request though if changed to this, as not to reuse the same header value between requests, and...I'm not quite sure where that logic should go now that I look at what's possible with RestEase.

[Chris-Johnston]

Given that this property may change very frequently, I think this approach would also require considering thread saftey

[AntiTcb]

Forgot to consider that. Do you know if the endpoints you've added the header param for are the only ones that actually do anything if you specify the audit log header?

[Chris-Johnston]

I went off of the list of events in the Audit Log documentation and tried to match each one. I have not tested each one individually.

[Auralytical]

These should probably be Utf8String? Also testing is needed before it can be approved.

[Chris-Johnston]

Currently I don't know of a good way to test this behavior without making the mock REST server return something that it shouldn't. The server and these tests don't have any state, so we can't just test them with the AuditLogController.

I've been able to at least check that this header is being sent as part of the request by mangling one of the tests and it's controller (in addition to using debugging tools):

[HttpDelete("channels/{channelId}")]
public async Task<IActionResult> DeleteChannelAsync(Snowflake channelId)
{
    Utf8String reason = null;
    if (Request.Headers.ContainsKey("X-Audit-Log-Reason"))
    {
        reason = new Utf8String(Request.Headers["X-Audit-Log-Reason"]);
    }

    return Ok(new Channel
    {
        Id = channelId,
        Name = reason
    });
}

[Fact]
public void DeleteChannelAsync()
{
    RunTest(c => c.DeleteChannelAsync(123, new Utf8String("This is my reason")), x =>
    {
        Assert.Equal(123UL, x.Id.RawValue);
        Assert.Equal("This is my reason", x.Name.ToString());
    });
}

This way I can see that the header is sent, but of course it modifies the output from what we should be expecting. If anyone has any suggestions I'd like to know how this could be tested better.

[Auralytical]

Sorry, I specifically meant about your comment I have not tested each one individually. lol. My current test setup doesn't expose a good way to build a test around this right now, so lets put that off for now.