use native BigInt instead of the big-integer library

[mariuz]

use native BigInt instead of the big-integer library. This removes the dependency and uses the performant modPow implementation

Changes in lib/srp.js
Removed require('big-integer').
Replaced BigInt(val, 16) with BigInt('0x' + val).
Replaced library methods (.multiply, .add, .mod, etc.) with native operators (*, +, %).
Added the modPow helper function at the end of the file.
Updated toBigInt and toBuffer helpers to handle native BigInt.

Changes in test/srp.js
Removed require('big-integer').
Updated test vectors to use native BigInt syntax (prefixed with 0x).
Replaced .equals() assertions with strict equality ===.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt

[mariuz]

The authentication failure was caused by a conflict between the big-integer library and JavaScript's native BigInt implementation, leading to data corruption in the SRP key exchange.

The Root Causes
Variable Shadowing: In lib/wire/connection.js, the line const BigInt = require('big-integer'); shadowed the global native BigInt constructor. This meant that when the code called BigInt(...), it created a big-integer library object instead of a native primitive.

Incorrect Hex Parsing: When parsing the server's public key:

javascript
public: BigInt('0x' + d.buffer.slice(...).toString('utf8'))
The big-integer library defaults to base-10 (decimal) parsing. Passing a string starting with 0x to it often results in 0 or incorrect parsing, whereas native BigInt correctly interprets the 0x prefix as hexadecimal.

Data Corruption via String Conversion: Even if the big-integer object held the correct value, passing it to lib/srp.js caused corruption. The toBigInt helper in test/srp.js converts inputs to strings:

javascript
const str = String(hex); // big-integer.toString() returns DECIMAL (base 10)
return BigInt('0x' + str); // Interprets those DECIMAL digits as HEX
Example:

Value: 16
big-integer string: "16"
test/srp.js interpretation: 0x16 (which is 22 in decimal)
This mismatch meant the client and server were using mathematically different keys, causing the proof verification to fail.

The Fix
Removing the big-integer dependency allows connection.js to use the native BigInt implementation, ensuring consistent hexadecimal parsing and compatibility with test/srp.js).