Correcting behaviour of BadRequests returning InternalServerError

[ayush3797]

Why make this change?

• Closes [Fuzzing] HTTP 500 - Insert Operation conflicting with ForeignKey constraint #620
  Previously, for exceptions that were arising because of users sending bad request to the database rather than an Internal Server failure of the database, we were still throwing exception with status code 500 (InternalServerError) rather than (400) BadRequest. This PR changes that behaviour to thrown exception with status code 400.

Useful Links

1. MsSql Error Codes
2. MySql Error Codes
3. PostgreSql Error Codes

What is this change?

We will now have 3 seperate subclasses of DbExceptionParser. The 3 subclasses for MySql, MsSql, PostgreSql will have their own implementation of the method IsBadRequestException(), which depending on the database's way of classifying exceptional conditions via SqlState(MySql/PgSql) or Number(MsSql), will return a boolean value indicating whether the exception is to be considered to have occurred because of a bad request.

Also the severity of Stylecop ruleCA1051 was reduced to suggestion to declare a protected field in DbExceptionParser class.

How was this tested?

• Integration Tests

[Aniruddh25]

Some questions..

[Aniruddh25]

LGTM

[seantleonard]

Some last nit comments to resolve and then looks good!

[aaronburtle]

mentioned this in another comment, but I think that comment might have been buried from updates. If MsSql is the only case here e.SqlState can be null, and MsSql never calls into this function, do we still need the null check?

[ayush3797]

I don't think SQLSTATE will be null in mysql,pgsql but as a defensive approach I am putting this null check because the string SQLSTATE is nullable in declaration.