[receiver/oracledb] Fix incorrect values for a couple of metrics

[crobert-1]

Description:

Values were being scraped incorrectly for the metrics oracledb.tablespace_size.limit and oracledb.tablespace_size.usage. The changes these metrics to be scraped from the DBA_TABLESPACE_USAGE_METRICS table. This results in a slight loss of granularity in these metrics, as values will always be in multiples of the respective tablespace's block size, but I think the clarity and simplicity is worth the trade off.

Note: The value of the usage metric was generally close to the expected value, but the limit was being calculated as potential theoretical capacity, unbound by server capacity. For example, in testing in a docker container on my local machine, limit was set to 17TB. This doesn't line up with user expectations.

Link to tracking Issue:
Fixes #31451

Testing:
Updated existing tests, added a couple new ones.

Also, the original issue filed was comparing DBA_TABLESPACE_USAGE_METRICS output for percent used to what we got from usage/limit * 100. Here's the local testing outputs compared to show they now line up.

2024-03-27T16:31:57.938-0700    info    oracledbreceiver/scraper.go:285 DBA_TABLESPACE_USAGE_METRICS: Tablespace name: SYSTEM, used space: 111288, tablespace size: 3518587, percent used: 3.16286054600895188892586711654422641816    {"kind": "receiver", "name": "oracledb", "data_type": "metrics"}

Metric #20
Descriptor:
     -> Name: oracledb.tablespace_size.usage
     -> Description: Used tablespace in bytes.
     -> Unit: By
     -> DataType: Gauge
NumberDataPoints #0
Data point attributes:
     -> tablespace_name: Str(SYSTEM)
StartTimestamp: 2024-03-27 23:31:56.873576 +0000 UTC
Timestamp: 2024-03-27 23:32:12.523295 +0000 UTC
Value: 911671296

Metric #19
Descriptor:
     -> Name: oracledb.tablespace_size.limit
     -> Description: Maximum size of tablespace in bytes, -1 if unlimited.
     -> Unit: By
     -> DataType: Gauge
NumberDataPoints #0
Data point attributes:
     -> tablespace_name: Str(SYSTEM)
StartTimestamp: 2024-03-27 23:31:56.873576 +0000 UTC
Timestamp: 2024-03-27 23:32:12.523295 +0000 UTC
Value: 28824264704

Doing the same calculation, we get:

(911671296 / 28824264704) * 100 = ~3.16%

[crobert-1]

The logic for setting this metric's value now requires two DB values to be multiplied by each other. This means we have to manually convert both values to int64, multiply them, then use that result to set the value here. Converting back to string just to convert to int64 again is unnecessary, so I've removed this option.

[crobert-1]

Feedback on indentation here would be helpful, not sure what's the most clear here.

[atoulme]

It was readable enough. I had a bit of hesitation that the query itself is 2 separate subqueries, joined via a where statement with a bigger query. It feels like an inner join could do the job, but my SQL is rusty and this is an improvement over the broken functionality. Maybe something to explore if it becomes a performance flare up, which I doubt.

[crobert-1]

Fair point. I added a benchmark test locally to compare this query vs. inner join, here are the results.
Inner join:

BenchmarkSQLUsageMetrics-16    	     150	   6881141 ns/op
BenchmarkSQLUsageMetrics-16    	     180	   6503225 ns/op
BenchmarkSQLUsageMetrics-16    	     172	   6594906 ns/op
BenchmarkSQLUsageMetrics-16    	     154	   6556032 ns/op

Two separate queries:

BenchmarkSQLUsageMetrics-16    	     132	   8800545 ns/op
BenchmarkSQLUsageMetrics-16    	     122	   8808408 ns/op
BenchmarkSQLUsageMetrics-16    	     118	   9132146 ns/op
BenchmarkSQLUsageMetrics-16    	     120	   8762194 ns/op

I'll update to use the inner join 👍